From: "Victor \"Zverok\" Shepelev" <vshepelev@...>
Date: 2006-12-06T08:16:53+09:00
Subject: Re: Lisp comprehensions => SQL

From: David Vallner [mailto:david@vallner.net]
Sent: Wednesday, December 06, 2006 12:59 AM
>To: ruby-talk ML
>Subject: Re: Lisp comprehensions => SQL
>
>Victor "Zverok" Shepelev wrote:
>> Hi all.
>>
>> Random idea, just for fun - using "list comprehensions" for SQL queries
>> generation.
>>
>
>I think it has been done verbatim, can't recall the library. Search the
>archives?

Hmm... can't imagine right keywords for search (as "list comprehension"
returns no likewise results).

>> Also MS's LINQ and ruby's Mongoose DB seems to do something like this.
>>
>
>MS's LINQ does the opposite, allowing SQL-ish constructs to express list
>comprehensions on steroids. Well, basically; I have my doubts about the
>more relational features like joins on object collections performing any
>well (no concept of the dataset, no analysis thereof to do query
>planning, probably no indexing either) or making actual sense whatsoever
>(why join when you can just use direct references?). From a design point
>of view, I'd prefer preintegrating data into a clean domain model
>instead of bridging over with the band-aid that is generalised data
>structure query. It's boilerplate, more effort, and less "whoa, cool",
>but you get a high level of consistency in the core business logic if
>you take care of the data format impedance mismatch up front instead of
>putting over a bandaid later. (No "What paradigm am I coding THIS line
>in again?" issues.) The field of data modelling seems way too varied to
>me for one query language / paradigm to work universally without kludges
>appearing around the edges.

OK, I've taken your point.
Just 2 notes:
1. I was really inspired by Links language - but it is from Haskell's author
Phil Wadler, therefore completely functional.
2. My typical task is small desktop programs in a manner of "usable
proof-of-concept", so, they are just a mix of clean-and-simple-concepts and
pretty-quick-hacks. The idea discussed looks close to latter :)

>(For the obvious impaired: I just don't like LINQ. By far the ugliest
>and most out of place addition to C#3.0.)

Yeah, completely agreed. I was mentioned it only as Phil Wadler did.

>> But the realization of above seems to be interesting task (for RubyQuiz,
>may be?)
>>
>
>Well, to work with blocks, you'd need to involve ParseTree or something
>like that, unless you're willing to offload some of the logic back to
>the interpreter (gruesomely laggy). That might be a little out of scope
>for a RubyQuiz. 

No-no. I think about some very simple, like special objects taken into
blocks, which translates its methods <, >, ==, && to something, which can be
done as SQL. That's why I consider it as an interesting task (despite of
your treating of overall idea).

V.