"Rather than defining tables themselves, you define attributes that can be used on any table, using defattributes like so"
This seems to imply a deep constraint that an attribute name MUST always be validated and handled the same way. A pretty serious limitation, IMO...
Also, if you're using a SQL client that makes "Parameterization of 'BOB' into a variable lack elegance", I'd recommend getting a better SQL client. Placeholders are SQL Interface 101 stuff.
Sorry if the documentation is lacking; you can put anything you want in an attribute. Defattributes is simply a convenience macro that defines validation functions (as well as row getter functions) that you can use if you want, or not.
Generally SQL parameterization interfaces (in mainstream languages) involve syntax like:
execute("SELECT * FROM FOO WHERE BAR = ?bar AND BAZ = ?baz", {'bar': bar, 'baz': baz})
At best you have something cleaner in languages with string interpolation, but the use of string interpolation itself is debatable.
I stand by the claim that those approaches lack elegance, but if it's really "SQL Interface 101" to do it better, please share some examples. I'd be curious to see them.
To be fair, most of a relational database is not in the query, but the query planner, the scheduler, and transaction management.... this is great syntax, but doesn't offer much more than that.
EDIT: Ironically for a "functional" language, this strikes me as more of a LINQ-type library that provides a query across an in-memory structure.
I'm amused because LINQ is basically a query monad, and can easily be implemented in terms of lazy lists and the standard functional operations on collections. I would think something like this would be built in to the collection library.
Woah! This is really cool, and represents some of the same ideas I have for a database/cache except in JS rather than LISP. I'd love to compare notes - http://github.com/amark/gun .
Disclaimer: I am not a Lisp hacker. I prefer to ship.
The syntax for this query language is beautiful. Really exceptional. Lisp has such an excellent way of representing deterministic programming that no other language has really been able to match.
I know this doesn't scale right now, but I don't see any reason why it couldn't at some point. The query syntax is much more digestible than SQL.
LambdaLite creator here. I just wanted to point out, in case it is not clear, that LambdaLite doesn't really introduce a new query language per se. The syntax is just "write any Lisp code you want" because actual Lisp closures are used where expressiveness is needed. Hopefully, this means the learning overhead is actually less: instead of needing to know both Lisp and SQL, you only need to know Lisp. (Disclaimer: obviously there is still an API to learn, but that would be the case with any SQL client library too.)
Because the tree structure of the parenthesized expression matches the structure of the query, manipulation of this tree using editor support such as Paredit is useful.
Lispers don't always realize that too many parens/brackets is a code smell in almost any other language. It makes people unnecessarily wary of (stuff (like 'this)).
I dunno. If I have a "complex" condition with more than two parts to it, I prefer to be liberal with parenthesis, rather than expect any future maintainer to remember all the operator precedence rules.
[1] http://en.wikipedia.org/wiki/ACID
[2] http://en.wikipedia.org/wiki/Relational_database#Constraints