On 2013-11-12 22:55, Philippe Sigaud wrote:

> Which you still have to mixin, btw. Which means any tree manipulation
> you do must be done at compile-time.
> Unless, of course,  you then put the resulting code into another file,
> to be compiled and loaded afterwards.

It would be at compile time with macros anyway. The DIP even says that the macro functions are removed in the code generating phase.

> *cough cough*
>
> But, as other have said, these would be very un-hygienic macros, with
> no knowledge of the surrounding environment.
> Unless said CT-compatible parser could also somehow determine the
> local symbols (you could pass it 'by hand', but who would do that,
> realistically?)

Exactly.

-- 
/Jacob Carlborg

On 11/13/2013 12:03 AM, Jacob Carlborg wrote:
> Again, operator overloading in D is too limiting to implement something Linq like.

Ok, let's set aside the opEquals and opCmp issue for the moment.

Can AST macros do anything that expression templates cannot?

Am 13.11.2013 09:34, schrieb luka8088:
> What about something like this?
>
> class Person {
>
>    macro where (Context context, Statement statement) {
>      // ...
>    }

it is not generic - and that is the biggest goal to reach

On Wednesday, 13 November 2013 at 08:45:13 UTC, Walter Bright wrote:
> On 11/13/2013 12:03 AM, Jacob Carlborg wrote:
>> Again, operator overloading in D is too limiting to implement something Linq like.
>
> Ok, let's set aside the opEquals and opCmp issue for the moment.
>
> Can AST macros do anything that expression templates cannot?

With an expression template you still can't create a statement. It has to revolve to a declaration.

But as I said before, it's primarily syntax sugar. Expression templates are just a mass of boilerplate code. I came to the conclusion that the code for expression templates was no less ugly than for string mixins.

What is true, though, is everything an AST macro can do, can already be done with a string mixin. The syntax is just ugly.

                 calling syntax power  implementation
string mixin       ugly         high      ugly
expr template       ok          low       ugly
AST macro          good          ?         ?

On Wednesday, 13 November 2013 at 08:45:13 UTC, Walter Bright wrote:
> On 11/13/2013 12:03 AM, Jacob Carlborg wrote:
>> Again, operator overloading in D is too limiting to implement something Linq like.
>
> Ok, let's set aside the opEquals and opCmp issue for the moment.
>
> Can AST macros do anything that expression templates cannot?

Yes, they can reflect the ast provided and act accordingly.

On Tue, 12 Nov 2013 14:38:43 -0000, John Colvin <john.loughran.colvin@gmail.com> 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 is often confused with LinqToSQL, the above was a description of what happens in the latter.  If Person was an object representing a table from a SQL database, then calling 'where' on it would translate into an IQueryable<Person> object which when iterated upon using foreach would execute the SQL statement shown above and return the resulting rows as <someperson> objects one by one to the foreach body.

Pure Linq is a DSL, an alternate syntax, which looks a lot like SQL, which can translate to SQL but is not limited to SQL.  It could translate to any alternate database syntax, or simply access a container supporting the required operations.

The motivation is the same as for "foreach", it is a general syntax for accessing a wide range of containers including databases with a common syntax.  We could, equally, go the other way, use the IMO nicer composition syntax X.where(..).foo(...).etc and translate that to SQL, without the need to the SQL like DSL inside D.

For some LINQ examples, see:
http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b

For a specific where example using a simple container, see "Where - simple 1"

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Am 13.11.2013 10:58, schrieb Regan Heath:
> Linq is often confused with LinqToSQL, the above was a description of what
> happens in the latter.  If Person was an object representing a table from
> a SQL database, then calling 'where' on it would translate into an
> IQueryable<Person> object which when iterated upon using foreach would
> execute the SQL statement shown above and return the resulting rows as
> <someperson> objects one by one to the foreach body.
>
> Pure Linq is a DSL, an alternate syntax, which looks a lot like SQL, which
> can translate to SQL but is not limited to SQL.  It could translate to any
> alternate database syntax, or simply access a container supporting the
> required operations.

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

Am 13.11.2013 11:41, schrieb dennis luehring:
> Am 13.11.2013 10:58, schrieb Regan Heath:
>> Linq is often confused with LinqToSQL, the above was a description of what
>> happens in the latter.  If Person was an object representing a table from
>> a SQL database, then calling 'where' on it would translate into an
>> IQueryable<Person> object which when iterated upon using foreach would
>> execute the SQL statement shown above and return the resulting rows as
>> <someperson> objects one by one to the foreach body.
>>
>> Pure Linq is a DSL, an alternate syntax, which looks a lot like SQL, which
>> can translate to SQL but is not limited to SQL.  It could translate to any
>> alternate database syntax, or simply access a container supporting the
>> required operations.
>
> linq allows construction AND querying of non table-like hierarchical
> data, so its more an (basetypes|object)-hierarchy store/retrival system
> which can "also" work with the lower just-tables-like world of sql results
>

but linq isn't good in graph operations like neo4j
http://www.neo4j.org/learn/cypher

which woulds be also very nice as an macro feature for in D reference traversing

On 12.11.2013 18:53, Ellery Newcomer wrote:


> Place.objects.filter(name="Bob's Cafe")
[snip]
> C. it would look like even worse crap in D (no named parameters!)

It's perfectly possible in D to make this work:

    Place.objects.filter(args.name = "Bob", args.state = "unemployed");


Proof of concept:

import std.stdio : writeln;

struct NamedArg(string name, Args...) {
    Args value;
    alias value this;
}

struct args {
    @property
    static auto opDispatch(string name, Args...)(Args args) {
        return NamedArg!(name, Args)(args);
    }
}

void foo(NamedArg!("name", string) a) {
    writeln(a);
}

void main() {
    foo(args.name = "Bob");
}

And since the name is statically known, you can use this for e.g. lookup on objects.

No, it's nowhere near as pretty, and the receiving code is horrible. If you were to use this for some kind of magic behind the scenes, it might be okay. Might. Please don't do it.


> 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))

Sorry, I got nuffin'. :p


Waaait...

  Places.where(args.elev.lessThan(200) & args.state =
        (state)=>Addresses.any(state));

I *can* make that work. I'm not going to.

--
  Simen

> From my point of view this whole idea is great as it makes it easier
> what is already possible. For example, with current behavior if I wanted
> to write.
>
> foo {
>   writeln("foo");
>   writeln("foo again");
> }

Currently this would be sent as a string. I have suggested previously (given a lexer implementation) a lexer would be included that can work by line and symbol. This is fine but it would mean the lexer would need to parse it before calling the macro itself. Perhaps it should be explored a forced parsing and validation of macro values?

> I would have to write:
>
> mixin(foo!(q{
>   writeln("foo");
>   writeln("foo again");
> }));

AST macros currently suggested do not work at the same stage as mixins, as far as I am aware. They work at a much earlier stage. Mixins have limits because of there lateness in lexing process.

> So the proposed behavior looks much nicer, and I agree with it as the
> content of foo block is actually written in D and I think whoever is
> reading it would be comfortable with it.
>
>
> However, for other, non-D syntax-es I would prefer something like:
>
> query q{
>   from element in array
>   where element > 2
>   add element to data
> }

I find it intriguing to add a keyword to distinguish a D code block from a string. As currently they are parsed the same way.

> Which can be handled by:
>
> macro query (Context context, string dsl) {
>     return domainSpecificLanguageToD(dsl);
> }
>
> This in terms is already possible by writing the following, it only
> allows to be written in a more readable way. And the q{ ... } notation
> clearly points out that there is something special going on. Also by
> passing such content as string user can implement custom (or call one of
> the predefined) tokenizer/lexer/parser.
>
> mixin(query!(q{
>   from element in array
>   where element > 2
>   add element to data
> }));

Perhaps a different way of identifying such code is required?

query "{
   from element in array
   where element > 2
   add element to data
}

Although it would act as a triple quoted string, except only valid for macros maybe? This would signify that the following block of text was to be pushed into a macro. Otherwise it would be assumed as valid D code?

Assuming a lexer is available it could check that any code given to a macro is correct. I will be submitting a pull request for pragma error and warning so if it is not valid the macro could fire a compile error.