LambdaLite: A functional, relational Lisp database in 250 lines of Common Lisp | Hacker News Reader

LambdaLite: A functional, relational Lisp database in 250 lines of Common Lisp

github.com

126 pointsjuliangamble20 comments

Cool. It seems to satisfy the A & D of the ACID properties [1]. The C is not-applicable as there isn't a notion of schema or constraints [2].

[1] http://en.wikipedia.org/wiki/ACID

[2] http://en.wikipedia.org/wiki/Relational_database#Constraints

"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 confused about your scare quotes around functional. LINQ is, for all intents and purposes, a functional extension of collections.

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 .

Nice work! Great to see new CL projects.

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.

I would still prefer

    (select :/name, :/salary from :employees where :/division = division)

I don't think these additional parentheneses add enough value to justify people learning another reinvention of sql.

It should be possible to make it accept regular sql syntax, just with added /column for table columns and referencing variables from inside.

Anyway, nice work.

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.

Non-lispers don't always realize that more parens can actually be a feature :)

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)).

Its().just().the().same().for().us().lispers().abstractFactoryFactory()

Why not both?

Quasiquote is going into Java 9.

And I wouldn't want to write sql like that ;)

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.

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.)

> I am not a Lisp hacker. I prefer to ship.

You make the two sound mutually exclusive.

Reply on news.ycombinator.com