On 2013-11-13 09:45, Walter Bright wrote:

> Ok, let's set aside the opEquals and opCmp issue for the moment.
>
> Can AST macros do anything that expression templates cannot?

I need to read up on what expression templates can do.

-- 
/Jacob Carlborg

On 2013-11-13 09:38, Walter Bright wrote:

> What's special about it was its use of expression templates. It made for
> a nice demo of how to do such.

Is there an actual point in doing that, except a nice exercise in expression templates?

-- 
/Jacob Carlborg

On 2013-11-13 09:34, luka8088 wrote:

> What about something like this?
>
> class Person {
>
>    macro where (Context context, Statement statement) {
>      // ...
>    }
>
> }
>
> auto foo = "John";
> auto result = Person.where(e => e.name == foo);
>
> // is replaced by
> auto foo = "John";
> auto result = Person.query("select * from person where person.name = " ~
> sqlQuote(foo) ~ ";");

That's basically what would happen.

-- 
/Jacob Carlborg

On 2013-11-13 10:58, Regan Heath wrote:

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

My original example was not Linq. I tried to make it look as much as ranges as possible. Yes, I'm tinking something like what you're suggesting:

Post.where(e => e.title == "Foo" && e.comments.title == "Bar").join(e => e.comments);

-- 
/Jacob Carlborg

On 2013-11-13 09:15, luka8088 wrote:

> I took a look at it as here is my conclusion for now:
>
> Statement and attribute macro examples look great. But I don't like Linq
> example. I don't think code like the following should be allowed.

I'm not a fan of the Linq example either. Or rather if I put it like this. I think the Linq example is quite a good example what can be done with AST macros. But I don't think it's a good fit in D.

> query {
>    from element in array
>    where element > 2
>    add element to data
> }
>
>
>  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");
> }
>
> I would have to write:
>
> mixin(foo!(q{
>    writeln("foo");
>    writeln("foo again");
> }));
>
> 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:

Well, the macros in the DIP only supports the D syntax. The macros work at the semantic level. You cannot create new syntax but you can give existing syntax new meaning. Compared with current D, macros need to lex and parse correctly. But they don't need to be semantically correct. That's the same thing as with templates, they can be semantically invalid as long as they're not instantiated.

The Linq example is lexically correct. I'm not sure if the parser will reject it or not.

> query q{
>    from element in array
>    where element > 2
>    add element to data
> }
>
> 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
> }));
>
>
> I also don't like the <[ ... ]> syntax because:
> 1. Like others have said, it looks very foreign.
> 2. I don't think there is a need to add a new syntax.

As it says in the DIP, this is one suggestion of the syntax, if new syntax is needed at all. It's just easier to show examples like that than building a complete AST with function calls.

As you can see I have an alternative that doesn't require new syntax:

http://wiki.dlang.org/DIP50#The_AST_Macro

Instead of "<[ a + b ]>" you would do "ast(a + b)" or "ast { a + b }".

> I think that string concatenation is enough (at least for now), and if
> you want another syntax for templates you can write a macro for that.

Strings are far from enough. Then you have missed the whole idea. It's not supposed to be syntax sugar for string mixins.

-- 
/Jacob Carlborg

On 2013-11-13 12:49, Rikki Cattermole wrote:

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

I think macros would work on the same stage as mixins.

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

All macro invocations are already checked. They're lexed and parsed. Marcos work at the semantic phase. Then when the macro is returned the resulting AST is typed checked as usual.

-- 
/Jacob Carlborg

On 13.11.2013. 13:26, Jacob Carlborg wrote:
> On 2013-11-13 09:34, luka8088 wrote:
> 
>> What about something like this?
>>
>> class Person {
>>
>>    macro where (Context context, Statement statement) {
>>      // ...
>>    }
>>
>> }
>>
>> auto foo = "John";
>> auto result = Person.where(e => e.name == foo);
>>
>> // is replaced by
>> auto foo = "John";
>> auto result = Person.query("select * from person where person.name = " ~
>> sqlQuote(foo) ~ ";");
> 
> That's basically what would happen.
> 

May/Should I add such example to wiki?

--
Luka

On 2013-11-13 15:47, luka8088 wrote:

> May/Should I add such example to wiki?

Yes, "should". Sure, add it to the DIP.

-- 
/Jacob Carlborg

On Wednesday, 13 November 2013 at 08:26:52 UTC, Jacob Carlborg wrote:
>
> I'm using a pluign to Ruby on Rails that does something similar but by overloading operators. The problem with this approach, in Ruby, is that you cannot overload operators like || and &&, so instead they overload | and & resulting in new problems like operator precedence. Example:
>
> Person.where{ |e| (e.name == "John") & (e.address == "Main street") }

Is this in any way better than the basic Ruby

  where( name: 'John', address: 'Main street' )

?  Or was it just something quick and contrived to show the behavior, and not the utility, of the plugin?  Just curious.

On Wednesday, 13 November 2013 at 10:51:48 UTC, Simen Kjærås wrote:
> On 12.11.2013 18:53, Ellery Newcomer wrote:
>
> It's perfectly possible in D to make this work:
>

hey, cool impl

*comprehends code*

I mean Ewww

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

I concur with the second part.