Am 03.02.2013 08:15, schrieb dennis luehring:
> Am 01.02.2013 12:24, schrieb Timon Gehr:
>> On 02/01/2013 11:54 AM, Jacob Carlborg wrote:
>>> ...
>>>
>>> Sounds like an ugly hack for AST macros. This is a proposal for AST
>>> macros I've been working on. It's not finished but here it is:
>>>
>>> https://dl.dropbox.com/u/18386187/ast_macros.html
>>>
>>
>> Make sure to include some way to pattern match on the syntax trees.
>> (Otherwise we are back to manual parsing of the ast.toString() output.)
>>
>
> from the text
>
> "...The first parameter of macro is always of the type Context..."
>
> is then there a real need for context as an parameter - it semanticly
> similar to "this" in the class scope - i would prefer a "context"
> keyword inside of the macro scope
>

i understand that pushing the context und sub-macro is a need

but didn't you define a macro-type by

alias macro (Ast!(string) str) my_macro

and this type can be used by sub-macros like normal typed parameters

another question:

why Ast! here - can the input any else than a AST?
and why not use your $ notation not also here $string?

On 2013-02-03 08:15, dennis luehring wrote:

> from the text
>
> "...The first parameter of macro is always of the type Context..."
>
> is then there a real need for context as an parameter - it semanticly
> similar to "this" in the class scope - i would prefer a "context"
> keyword inside of the macro scope

One reason is to not have to introduce a new keyword, which in general is not very popular around here.

Note that "macro" keyword is already reserved for future use, just for a feature like this.

-- 
/Jacob Carlborg

On 2013-02-03 09:44, dennis luehring wrote:

> i understand that pushing the context und sub-macro is a need
>
> but didn't you define a macro-type by
>
> alias macro (Ast!(string) str) my_macro
>
> and this type can be used by sub-macros like normal typed parameters

I'm not sure I understand the above.

> another question:
>
> why Ast! here - can the input any else than a AST?
> and why not use your $ notation not also here $string?

Ast would be a type defined, most likely, by druntime. I'm trying to minimize the syntactic changes needed to implement this feature request. It's not even sure that the $val syntax would be used. Take a look at the "ast" macro.

-- 
/Jacob Carlborg

On 2013-02-03 03:36, timotheecour wrote:
> seems like my original post regarding __ARGS__ was completely hijacked
> by the discussion on AST macros (however fruitful and interesting). I
> agree macros would solve this issue while providing a much more general
> solution, however, it's very unclear when that would be implemented,
> surely not anytime soon.
>
> Is there any other feedback on introducing __ARGS__  (see first post)
> besides AST macros being better? It's much simpler implementation-wise.

Sorry about that. I don't think that __ARGS__ is a bad idea, I just think that there are several features in D which could be replaced with a library solution using AST macros (if those were available).

-- 
/Jacob Carlborg

Jacob Carlborg wrote:

> On 2013-02-01 11:34, timotheecour wrote:
>> One of the rare features I miss in C/C++ is stringification macro using "#x":
>>
>> ---
>> #include ...
>> #define DEBUG(x) disp_val(#x,x)
>> template<typename T>
>> void disp_val(const char*name, const T& x) {std::cout << name << "=" << x;}
>> int main(){
>> DEBUG(1+2); //will print 1+2=3 (and we can add line, file and func info)
>> ASSERT(1+2==4); //can also be defined such that it'll print 1+2==4
>> failed...
>> }
>> ---
>>
>> In D, we have built-in assert message that'll print the failing expression "1+2==4 failed" in case of failure but that's about it: no further processing can be done on that message, and there's nothing we can do about the DEBUG(1+2) case. I did a function that requires one to write mixin(myDebug("1+2")); but that's not as good, especially because of the quoting that makes most IDE's unaware of the syntax inside (maybe monod would work but still...).
>>
>> However there could be a clean D solution that alleviates need for macros: I'd like to add __ARGS__ to the list of __FILE__, __LINE__, __FUNC___:
>>
>> P1) 1st proposal:
>> __ARGS__ is a string representing the comma separated list of arguments
>> passed:
>> void DEBUG(T,A)(T a, A args=__ARGS__){writeln(args,"=",a);}
>> void DEBUG2(T1,T2,A)(T1 a1,T2 a2, A args=__ARGS__){writeln(args);}
>> DEBUG(1+ 2); //will print "1+ 2=3", ie args="1+ 2"
>> DEBUG(1+ 2,
>> 3*3);
>> //will print "1+ 2,3*3" (ie normalize the comma separation)
>>
>> P2) same but __ARGS__ is string[] with one string per argument; the compiler already did the job of parsing, might as well use it:
>>
>> void DEBUG(T)(T a1, T a2, string[] args=__ARGS__){
>> writeln(args[0],"=",a1);
>> writeln(args[1],"=",a2);
>> }
>>
>> A question: whether or not to include the first argument in a
>> UFCS/member function call ("hello".fun(1+2) ).
>>
>> P3)
>> additionally, create a __CONTEXT__ that is a struct consisting of
>> __ARGS__,__FILE__, __LINE__, __FUNC___. This has been proposed before
>> and makes even more sense now. Additionally, it could give info on
>> whether the call was UFCS'd or not, etc, information which is lost
>> otherwise (I don't think traits could help distinguish which version was
>> called, a.fun(b) or fun(a,b)).
> 
> Sounds like an ugly hack for AST macros. This is a proposal for AST macros I've been working on. It's not finished but here it is:
> 
> https://dl.dropbox.com/u/18386187/ast_macros.html
> 

+1

Jacob, I humbly believe this should be a new DIP ... This proposal, if realised, would bring very useful feature to D...

-- 
Dejan Lekic
dejan.lekic (a) gmail.com
http://dejan.lekic.org

Dejan Lekic:

> Jacob, I humbly believe this should be a new DIP ...

I agree.


> This proposal, if realised, would bring very useful feature to D...

The Scala-style macros, with enough reflection (plus maybe pattern matching implemented with the macro themselves) are able to expand the flexibility of D.

But macros have some costs. They add complexity to the language, and make code that uses macros less easy to understand. The almost only good place to use macros is in well known and well debugged library code, standard code, like in Phobos.

Most D programmers are not going to be able to use macros. If you add macros you create even more the levels of programmers they talk about in Scala:
http://www.scala-lang.org/node/8610

One of the most powerful and useful features of CommonLisp (and similar languages) are macros. They add power to the language, but flexibility itself has a high cost. It makes hard for the programmer A to understand and use code written by programmer B. It goes against some of the things that foster the creation of an ecology of reusable modules as in Python and Perl. Too much flexibility is dangerous. Even Scala is risking that with its macros. Lot of programming situations where today Java is used aren't going to use Scala and its macros. Macros are both part of the power of Lisp and one of the causes of its "failure".

So it's a matter of balancing things: are macros going to give to D more than the (high) price they ask for? I like AST macros, but I don't know the answer.

Bye,
bearophile

On 2013-02-03 21:25, Dejan Lekic wrote:

> +1
>
> Jacob, I humbly believe this should be a new DIP ... This proposal, if realised,
> would bring very useful feature to D...

I'm not really sure what to do about hygienicy.

-- 
/Jacob Carlborg

On 2013-02-01 18:53, bearophile wrote:

> Maybe Jacob Carlborg is able to show what kind of syntax for pattern
> matching the macros are able to create (no need to actually implement it
> now).

How would a pattern matching feature look like and behave?. I can see if that would be possible to implement using the AST macros I'm thinking about.

-- 
/Jacob Carlborg

Jacob Carlborg wrote:

> On 2013-02-01 11:34, timotheecour wrote:
>> One of the rare features I miss in C/C++ is stringification macro using "#x":
>>
>> ---
>> #include ...
>> #define DEBUG(x) disp_val(#x,x)
>> template<typename T>
>> void disp_val(const char*name, const T& x) {std::cout << name << "=" << x;}
>> int main(){
>> DEBUG(1+2); //will print 1+2=3 (and we can add line, file and func info)
>> ASSERT(1+2==4); //can also be defined such that it'll print 1+2==4
>> failed...
>> }
>> ---
>>
>> In D, we have built-in assert message that'll print the failing expression "1+2==4 failed" in case of failure but that's about it: no further processing can be done on that message, and there's nothing we can do about the DEBUG(1+2) case. I did a function that requires one to write mixin(myDebug("1+2")); but that's not as good, especially because of the quoting that makes most IDE's unaware of the syntax inside (maybe monod would work but still...).
>>
>> However there could be a clean D solution that alleviates need for macros: I'd like to add __ARGS__ to the list of __FILE__, __LINE__, __FUNC___:
>>
>> P1) 1st proposal:
>> __ARGS__ is a string representing the comma separated list of arguments
>> passed:
>> void DEBUG(T,A)(T a, A args=__ARGS__){writeln(args,"=",a);}
>> void DEBUG2(T1,T2,A)(T1 a1,T2 a2, A args=__ARGS__){writeln(args);}
>> DEBUG(1+ 2); //will print "1+ 2=3", ie args="1+ 2"
>> DEBUG(1+ 2,
>> 3*3);
>> //will print "1+ 2,3*3" (ie normalize the comma separation)
>>
>> P2) same but __ARGS__ is string[] with one string per argument; the compiler already did the job of parsing, might as well use it:
>>
>> void DEBUG(T)(T a1, T a2, string[] args=__ARGS__){
>> writeln(args[0],"=",a1);
>> writeln(args[1],"=",a2);
>> }
>>
>> A question: whether or not to include the first argument in a
>> UFCS/member function call ("hello".fun(1+2) ).
>>
>> P3)
>> additionally, create a __CONTEXT__ that is a struct consisting of
>> __ARGS__,__FILE__, __LINE__, __FUNC___. This has been proposed before
>> and makes even more sense now. Additionally, it could give info on
>> whether the call was UFCS'd or not, etc, information which is lost
>> otherwise (I don't think traits could help distinguish which version was
>> called, a.fun(b) or fun(a,b)).
> 
> Sounds like an ugly hack for AST macros. This is a proposal for AST macros I've been working on. It's not finished but here it is:
> 
> https://dl.dropbox.com/u/18386187/ast_macros.html
> 

+1

Jacob, I humbly believe this should be a new DIP ... This proposal, if realised, would bring very useful feature to D...

-- 
Dejan Lekic
dejan.lekic (a) gmail.com
http://dejan.lekic.org

On 02/04/2013 01:36 PM, Jacob Carlborg wrote:
> On 2013-02-03 21:25, Dejan Lekic wrote:
>
>> +1
>>
>> Jacob, I humbly believe this should be a new DIP ... This proposal, if
>> realised,
>> would bring very useful feature to D...
>
> I'm not really sure what to do about hygienicy.
>

IMO macros should be fully hygienic by default, with opt-out options.