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...?

On Tuesday, 12 November 2013 at 14:38:44 UTC, John Colvin wrote:
> 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...?

I don't know much about linq but in macro context I'd expect it to generate an actual SQL query to database (and execute it) based on in-language filter statement (via reflection)

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)

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.

On 11/12/13 7:21 AM, Ellery Newcomer wrote:
> 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)

Maybe the problem needs to be reformulated for D. I think an SQL mixin that either stays unchanged (for DB engines) or translates to a D expression (for native D data types) would be doable, nontrivial, interesting, and instantly usable for people who already know SQL without any extra learning. In other words... actually better than Linq.

Andrei

On Tuesday, 12 November 2013 at 16:39:18 UTC, Andrei Alexandrescu wrote:
> Maybe the problem needs to be reformulated for D. I think an SQL mixin that either stays unchanged (for DB engines) or translates to a D expression (for native D data types) would be doable, nontrivial, interesting, and instantly usable for people who already know SQL without any extra learning. In other words... actually better than Linq.

It does not matter that much if it is macro or mixin. Key feature is AST reflection which allows to augment valid D code with additional semantics when appropriate. It is very similar to how UDA's augment declarative approach, but applied to imperative/procedural instead. We can't do that in D right now. Only way is to import own source file and parse it which does not really sound sane.

On 11/12/13 8:47 AM, Dicebot wrote:
> On Tuesday, 12 November 2013 at 16:39:18 UTC, Andrei Alexandrescu wrote:
>> Maybe the problem needs to be reformulated for D. I think an SQL mixin
>> that either stays unchanged (for DB engines) or translates to a D
>> expression (for native D data types) would be doable, nontrivial,
>> interesting, and instantly usable for people who already know SQL
>> without any extra learning. In other words... actually better than Linq.
>
> It does not matter that much if it is macro or mixin. Key feature is AST
> reflection which allows to augment valid D code with additional
> semantics when appropriate.

I don't see how AST reflection is needed for generating correct D code from an SQL expression. Dmitry did exactly that with ctRegex. Please illuminate.

Andrei

Am 12.11.2013 17:39, schrieb Andrei Alexandrescu:
> Maybe the problem needs to be reformulated for D. I think an SQL mixin
> that either stays unchanged (for DB engines) or translates to a D
> expression (for native D data types) would be doable, nontrivial,
> interesting, and instantly usable for people who already know SQL
> without any extra learning. In other words... actually better than Linq.

"actually better than Linq" good statement without knowing it deep

linq allows construction and querieng of non table-like hierarchical data, so its more an object-hierarchy store/retrival system which can "also" work with the lower just-tables-like world of sql results

On 11/12/13 8:56 AM, dennis luehring wrote:
> Am 12.11.2013 17:39, schrieb Andrei Alexandrescu:
>> Maybe the problem needs to be reformulated for D. I think an SQL mixin
>> that either stays unchanged (for DB engines) or translates to a D
>> expression (for native D data types) would be doable, nontrivial,
>> interesting, and instantly usable for people who already know SQL
>> without any extra learning. In other words... actually better than Linq.
>
> "actually better than Linq" good statement without knowing it deep
>
> linq allows construction and querieng of non table-like hierarchical
> data, so its more an object-hierarchy store/retrival system which can
> "also" work with the lower just-tables-like world of sql results

Yah, it was an exaggeration. Linq is very powerful.

Andrei

On Tuesday, 12 November 2013 at 16:54:19 UTC, Andrei Alexandrescu wrote:
> I don't see how AST reflection is needed for generating correct D code from an SQL expression. Dmitry did exactly that with ctRegex. Please illuminate.

Other way around. Generating arbitrary output (including but not limited to SQL expressions) from D code. As I have already mentioned, it is the very same thing we do now with __traits and UDA's but not limited to only declarations.