Linq and the like

[Ellery Newcomer]

On Tuesday, 5 February 2008 at 06:28:04 UTC, Don Clugston wrote:
> AFAICT, there's nothing in LINQ that D couldn't (in theory*) do 
> with a library -- today implemented using ctfe and mixins, in 
> future with the front end replaced by macros.
>
> IMHO, LINQ is a classic example of something that should be in 
> a library. If it can't be implemented in a library, then the 
> solution is to make the language more powerful, not to shove 
> the library into the compiler.
>
> * not in practice, mainly because of the compiler CTFE bug: 
> temporary strings never get deleted, so CTFE runs out of memory 
> extremely quickly.

LINQ is dependent on .NET's ability to decompose a lambda 
expression into a parse tree, e.g. in converting

qry = qry.Where(a => a.field == localvar);

into an appropriate sql where clause.

What I like about LINQ is it provides a centralized interface for 
high-level query operations that any .NET library worthy of the 
name is going to support. To some extent, ranges and 
std.algorithm, std.range, etc fills this space in D, but it trips 
up in terms of extensibility. A .NET ORM can support the LINQ 
interface; it is an interface and .NET provides the necessary 
tools to implement it (translation of a LINQ query to a SQL 
query).

A D ORM could (and would) support the range interface, but this 
is insufficient for a general query (e.g. you would usually want 
filter!pred(sqlresult) to be done by the database, not by 
std.algorithm). And std.algorithm is an implementation, not an 
interface.


I'm trying to think of how one would implement a rich query 
syntax for a D ORM, and the best I can come up with is something 
like

qry = qry.Where(a => a.eq(localvar));

where a is a proxy type that makes use of operator overloads and 
methods and maybe opDispatch that return query trees. But it's 
ugly. And you can't reuse predicates in ORM queries and phobos 
functions.

Can anyone else think of a better alternative?