DIP 50 - AST macros

[Ellery Newcomer]

On Tuesday, 12 November 2013 at 16:14:57 UTC, John Colvin wrote:
> On Tuesday, 12 November 2013 at 15:21:16 UTC, Ellery Newcomer 
> wrote:
>> On 11/12/2013 06:38 AM, John Colvin wrote:
>>> On Tuesday, 12 November 2013 at 13:50:49 UTC, Jacob Carlborg 
>>> wrote:
>>>> auto person = Person.where(e => e.name == "John");
>>>>
>>>> Translates to:
>>>>
>>>> select * from person where name = 'John'
>>>>
>>>
>>> for those of us entirely unfamiliar with linq, what is this 
>>> supposed to
>>> do? Select people with name "John" from a collection of 
>>> people, like in
>>> sql? It seems trivial to do this using filter, or am I missing
>>> something...?
>>
>> linq provides an interface to query any collection, but what 
>> is interesting in this case is
>>
>> Person.where(e => e.name == "John")
>>
>> invokes an engine that builds the necessary sql to issue an 
>> equivalent query to your sql database and assembles the 
>> results into a range of Person. And it can do this for any 
>> arbitrary predicate (well, almost. It doesn't handle function 
>> calls to arbitrary code too well).
>>
>> the .NET framework can do this because it exposes an api for 
>> querying, building, and compiling asts.
>>
>> D cannot do this because it doesn't. (and I have tried to make 
>> it work)
>
> oh, I see. Would AST macros really be enough to make this work 
> in D? "Arbitrary code" is a huge feature space in D, including 
> much that doesn't map well to anything outside of a relatively 
> low-level language, let alone SQL.
> I can see it quickly becoming a nightmare that would be worse 
> than just issuing the predicate as an sql string or some 
> generic equivalent.

Actually,

s/arbitrary code/simple to moderately complex expressions that 
don't call functions that aren't explicitly handled by the 
translation engine/

and this is a better representation of what linq can do in e.g. 
entity framework.

and you could go the route of django models, e.g.

Place.objects.filter(name="Bob's Cafe")

as long as you had enough metadata set up. you could probably get 
this to work in D, but

A. it looks like crap
B. it in no way resembles sql
C. it would look like even worse crap in D (no named parameters!)
D. it doesn't readily permit you to make queries with complex 
expression trees (idk, maybe something like linq's

Places.Where(p => p.Elev < 200 && Addresses.Any(a => a.State == 
p.State))

why am I arguing against this? nobody wants this, nobody asked 
for this.

Also, sql is to databases what assembly is to cpus. It's low 
level, [moderately] untyped, and it differs on every single 
platform. provide access to it, sure, but please don't use it to 
build your abstractions.