LISPOS: My manifesto
Tue, 31 Mar 1998 19:18:22 +6600 (CST)

[Snip... Lisp-isized SQL]

> If it's a traditional Scheme lambda, it's opaque to the select
> function.  This means that it is impossible to use indices.  That is,
> (select '(name) :from users :where (lambda (x) (= (acctnum x) 44833)))
> can't use the primary-key index on users by acctnum, it has to look at
> every record and call the lambda function on it.
> This means that what was originally a simple hash-table lookup and
> fetch, or possibly a b-tree lookup and fetch, becomes a process that
> requires fetching something like 50,000 records from disk and calling a
> couple of Scheme functions for each one of them.

Given the blatant disregard (or rather complete lack of consideration)
for performance I have for what is essentially a prototype for
another concept entirely, I don't find this issue bothersome at all.
As a matter of fact, I don't consider it an issue.

> This does not meet my definition of `essentially for free'.

But it meets mine.

I was speaking of price from the point of view of an implementor.
This is practically free for hir.  Performance is a price that
the user deals with -- I never mentioned that at all.

> However, I believe that you might reasonably be able to do it with
> slightly different syntax.
> (select '(name) :from users :where '(acctnum = 44833))
> This is also more readable to SQL folks.

But then we lose the flexibility of a lambda expression.  In
that case, we might as well not bother writing this.

> > (in this case lambda expressions give "where" tremendous
> > flexibility and power [I believe more so than the original SQL],
> I suspect that it is possible to incorporate lambda expressions into
> where clauses and order by clauses in a reasonable way.

Some compromise should be reached, because I would bitterly
oppose loss of the lambda expression in the where clause
at all costs -- even at the cost of the entire SQL project.

If it doesn't have lambda, then it isn't worth writing.

> Kragen