I know someone made scaffolding work earlier, but I don't know exactly how they did it.
Anyway, ideally with templates -- in my case, one for posts and one for tags -- you'd be able to make use of this relation in a functional way with no real performance issues.
I was the one who created the scaffolding system- It does, indeed, generate the code to add/update/etc from a database. I've continued to expand the system on my own, but since there wasn't much interest in the arc forum I decided not to continue checking code into anarki for now, but may again in the future- So right now it is strictly ver 0.01, though I'm surprised others seem to manage without a scaffolding system...
As for the issue of one-many and many-many, I guess I would suggest that in a one-to-many situation I would try and store the "many" as a child field in the "one", not use two separate tables if you can get away with it (one of the advantages of a non-RDBMS is that this design is possible)
As for many-many, I would probably have two tables, then have an extra table that just maps keys to keys for the two tables. Basically, just like an RDBMS association table. (or maybe even a bidirectional table, if you need to go "both ways")
If you want to know the "official" way to store data in different relationships in a simple, purely functional, memory resident database, I'd look at HApps-ixset. This is philisophically closely aligned to what you'd need in arc and is designed by some super smart guys. Unfortunately, their documentation is wanting or I'd point you to a good link that describes how to use it.
I've been thinking it might be possible to make these mappings implicit. Imagine you had a version of deftem (I'll call it defitem) that inspected the fields in your templates:
(defitem post
id nil
title nil
text nil
tags nil)
(defitem tag
id nil
text nil
post nil)
defitem would see that post has a relationship with tag and tag has a relationship with post by looking at the names of the fields in each template. Since the post field in tag is singular and the tags field in post in plural, it would know that there is a one-to-many relationship between post and tag. Then defitem could create any necessary accessor methods.
Anyways, that's what I've been attempting recently.
Just to add: if you want your function to take any number (including zero) arguments, then just use a symbol instead of an argument list, and all the arguments will be bound to that symbol.
So if you have
(def foo (a b . c) ...stuff...)
and you call (foo 1 2 3 4 5), a is bound to 1, b is bound to 2, and c is bound to the list (3 4 5).
And
(def foo a ...stuff...)
is just shorthand for
(def foo ( . a) ...stuff...).
So calling (foo 1 2 3) in this case means a is bound to the list (1 2 3).
1) Not feasible currently. 'foo.bar expands to (foo bar), so you're example would expand to (x y z), or ((1 2 3) (4 5 6) (7 8 9)) where (1 2 3) is being applied as a function.
While it could be implemented, I think it would only serve to further confuse existing syntax.
2) This require some serious hackery on integers to get that to work.
The learning curve is quite small. You're just learning a different thinking process than you're used to.
It might help for you to read "The Roots of Lisp" by Paul Graham, which will not only explain Lisp's core axioms, but also show you how they form other things in the language.
After that, I'd see if you can find a copy of "The Little Schemer" by Daniel P. Friedman and Matthis Felleisen, which will not only introduce you to sound functional concepts through the use of recursion, but do so by helping you write functions which are actually quite useful.
There is of course, much more literature out there that will go far more in-depth into Lisp, but these will provide a gentle introduction to the basics.
The learning curve is small if you have a math or cs education, if you've been exposed to another functional language or you naturally think in s-expressions.
If you are just a random python programmer and you looked at arc I could see it being challenging. The axioms of lambda calculus and functional programming are concise and simple but that doesn't mean the concepts they imply are also simple.
I agree The Little Schemer is a great book. Along with SICP, On Lisp, etc.
In the end it is worth the trouble to learn at least one lisp dialect. It'll improve your coding and make you question why you are writing imperative-language-001 all day long.
