Re: Scheme is too complicated

[hjstein@bfr.co.il (Harvey J. Stein)]

Per Bothner <bothner@cygnus.com> writes:

 > hjstein@bfr.co.il (Harvey J. Stein) writes:
 > 
 > | One interface I'm familiar with is the one which makes an underlying
 > | database file look like an associative array (aka hash table).
 > 
 > Sascha Ziemann <szi@aibon.ping.de> wrote:
 > > Consider a SQL query which returns more data than your computer has
 > > memory. I don't think that you will find a useful implementation that
 > > let's the result look like a hash table.
 > 
 > You missed the point.  "Looks like a hastable" does not imply that
 > it be implemented as an in-memory hashtable, only that it has a
 > similar programming interface.  (Notice also that Harvey talked
 > about the "underlying database file" and you talk about result
 > sets.)
 > 
 > The more important point is that an SQL table does *not*
 > look like hash table:  A table may have multiple keys,
 > can be retrieved in different search orders, and may have
 > various secondary indexes.  You can of course gain access
 > to all the records using a mapper and a filtering predicate;
 > the problem is you really want to translate the Scheme filter
 > predicate into SQL, so the database engine can do the right
 > optimizations and select the best indexes.  Doing that is
 > an interesting implementation challenge!

I think the two of you are thinking the same thing & we're all in
agreement.  I refrained from sending the same response because Sascha
wrote:

 > > I don't think that you will find a useful implementation that
 > > let's the result look like a hash table.

The key word in the above is *useful*.  There's not going to be a
*useful* SQL database interface that makes the database look like a
hash table.  There are useful Berkeley DB, GDBM, ... interfaces that
do that, but the SQL database interface needs to look different.

As for compiling scheme filters into SQL, it sounds like a nice thesis
project, but I'd think that some sort of "functional" SQL generation
would be sufficient.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il