On Wednesday, 27 May 2015 at 15:20:38 UTC, weaselcat wrote:
> On Wednesday, 27 May 2015 at 12:39:52 UTC, ixid wrote:
>> On Wednesday, 27 May 2015 at 12:34:49 UTC, Daniel Kozák wrote:
>>>
>>> On Wed, 27 May 2015 12:07:09 +0000
>>> Dennis Ritchie via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>>> On Wednesday, 27 May 2015 at 11:53:00 UTC, Jacob Carlborg wrote:
>>>> > I have thought of that too. But I haven't been able to come up with a syntax that looks good and doesn't conflict with any existing syntax/symbol. The above syntax is already used for template instantiation.
>>>> 
>>>> What if use the symbol '#' ?
>>>
>>> Yep, I like this symbol for macro too.
>>
>> What's wrong with using the word macro? We don't want symbol soup.
>
> this, there's a reason people don't use lisp.

Lisp is not used due to other reasons, symbol soup typical for Perl :)
$? ? s:;s:s;;$?: : s;;=]=>%-{<-|}<&|`{; ;
y; -/:-@[-`{-};`-{/" -; ;
s;;$_;see

On Wednesday, 27 May 2015 at 08:14:36 UTC, Kagamin wrote:
> On Tuesday, 26 May 2015 at 23:47:41 UTC, Dennis Ritchie wrote:
>> If this proposal is considered, it is required to propose to look
>> at the implementation of macros in Nemerle. Many believe that it
>> is in Nemerle macros implemented the most successful compared to
>> other modern languages. Of course, the most successful macros are
>> implemented in Lisp, but the syntax of the language is poor :)
>
> The problem with declarative macro system is that you would need to learn yet another language. Possibly turing-complete. And a declarative turing-complete language is an overkill both for usage and implementation. Imperative macros get it done in an intuitive way in the existing language.

But D already has such a declarative language - the one used in template metaprogramming. I think a macro system that plays well with that template metaprogramming sub-language will be really nice. For example, CTFE that works like a macro and returns types/aliases:

    Auto deduceType(Auto args) {
        // some complex imperative code to deduce the type from the args
        return DeducedType;
    }

    struct Foo(T...) {
        deduceType(T) value;
    }

On 05/27/15 17:47, Idan Arye via Digitalmars-d wrote:
> On Wednesday, 27 May 2015 at 08:14:36 UTC, Kagamin wrote:
>> On Tuesday, 26 May 2015 at 23:47:41 UTC, Dennis Ritchie wrote:
>>> If this proposal is considered, it is required to propose to look at the implementation of macros in Nemerle. Many believe that it is in Nemerle macros implemented the most successful compared to other modern languages. Of course, the most successful macros are implemented in Lisp, but the syntax of the language is poor :)
>>
>> The problem with declarative macro system is that you would need to learn yet another language. Possibly turing-complete. And a declarative turing-complete language is an overkill both for usage and implementation. Imperative macros get it done in an intuitive way in the existing language.
> 
> But D already has such a declarative language - the one used in template metaprogramming. I think a macro system that plays well with that template metaprogramming sub-language will be really nice. For example, CTFE that works like a macro and returns types/aliases:
> 
>     Auto deduceType(Auto args) {
>         // some complex imperative code to deduce the type from the args
>         return DeducedType;
>     }
> 
>     struct Foo(T...) {
>         deduceType(T) value;
>     }

That already works. Eg:

   alias deduceType(Args...) = typeof({
      // some complex imperative code to deduce the type from the args
      import std.range;
      return mixin(iota(Args.length).map!q{`Args[`~text(a)~']'}().join("+"));
   }());

   struct Foo(T...) {
      deduceType!(T) value;
   }

   static assert(is(typeof(Foo!(short, ubyte, bool).value)==int));


What all these proposals seem to be about is:

a) better introspection (ie exposing a (preferably simplified and std) AST)
b) AST injection
c) "better" syntax
d) better "optimizations", meaning skipping the emission of code and data
     that is never used at runtime.

artur

On 2015-05-27 14:17, Kagamin wrote:

> Well, that's the point: the function is a normal function, only some of
> its parameters require specially prepared arguments, this can't be
> missed as soon as arguments are passed to the respective parameters.

I prefer to be more explicit in this case, especially since the keyword is already available.

>> In that case I would prefer the "macro" keyword. It's already a
>> reserved, for exactly this purpose, so it will be backwards compatible.
>
> Well, maybe, I just didn't need the keyword.

I don't need it either, it's just what I preferred.

> No, passing of Context is not proposed.

The feeling I have it that it's hard to know if it's needed or not without implementing/using the macro system.

> I mean, the template instantiation syntax can inform the compiler that
> the expression is evaluated at compile time with possible code
> generation, so that the compiler is prepared to what macro will do. This
> resembles similarity between macros and templates. If macros can use
> existing syntax of a function call, I see no problem if they use another
> existing syntax.

True, but how would that the syntax look like for template macro, if possible?

-- 
/Jacob Carlborg

On Wednesday, 27 May 2015 at 19:15:34 UTC, Jacob Carlborg wrote:
> On 2015-05-27 14:17, Kagamin wrote:
>
>> Well, that's the point: the function is a normal function, only some of
>> its parameters require specially prepared arguments, this can't be
>> missed as soon as arguments are passed to the respective parameters.
>
> I prefer to be more explicit in this case, especially since the keyword is already available.

I think it's more important to be explicit in the macro invocation than in the macro declaration. You can tell from the macro declaration that it's a macro you are looking at, even without the `macro` keyword, but the proposed syntaxes offer no no way to tell between a regular function call and a macro invocation by looking at the callsite alone.

On 2015-05-27 21:41, Idan Arye wrote:

> I think it's more important to be explicit in the macro invocation than
> in the macro declaration. You can tell from the macro declaration that
> it's a macro you are looking at, even without the `macro` keyword,

It depends. As far as I can see, just looking at the macro declaration it's just a regular function declaration. You need to look at the types.

First, you need to know that "Auto" is a special type. Second, you need to know that it's only a special type if the fully qualified name is "core.macros.Auto".

It's not enough to look at the imports in the current module, since D supports public imports:

module foo;

public import core.macros;

module bar;

import foo;

Auto myAssert(Auto condition, Auto message)
{
    return message;
}

Not so easy to tell that "myAssert" is a macro declaration just by looking in the module "bar".

-- 
/Jacob Carlborg

On Wednesday, 27 May 2015 at 17:03:30 UTC, Artur Skawina wrote:
> That already works. Eg:
>
>    alias deduceType(Args...) = typeof({
>       // some complex imperative code to deduce the type from the args
>       import std.range;
>       return mixin(iota(Args.length).map!q{`Args[`~text(a)~']'}().join("+"));
>    }());
>
>    struct Foo(T...) {
>       deduceType!(T) value;
>    }
>
>    static assert(is(typeof(Foo!(short, ubyte, bool).value)==int));
>
>
> What all these proposals seem to be about is:
>
> a) better introspection (ie exposing a (preferably simplified and std) AST)
> b) AST injection
> c) "better" syntax
> d) better "optimizations", meaning skipping the emission of code and data
>      that is never used at runtime.
>
> artur

Maybe extending capabilities of templates would be a better direction. They already accept aliases which are essentially simple hygienic identifier expressions.

On Thursday, 28 May 2015 at 06:39:11 UTC, Jacob Carlborg wrote:
> Auto myAssert(Auto condition, Auto message)
> {
>     return message;
> }
>
> Not so easy to tell that "myAssert" is a macro declaration just by looking in the module "bar".

Well, that's the point: it's a normal function.

On 5/26/15 2:23 PM, Kagamin wrote:
> http://wiki.dlang.org/DIP78 - Proposal for a macro system without
> syntactical extensions to the language. Hence it doesn't allow arbitrary
> syntax.

Quote from dconf W&A ask me anything:

Q: "Will we get a macro system"

Both Walter and Andrei: "no"

Doesn't seem like much of a point for this proposal then. There didn't seem to be any wiggle room.

-Steve

On 2015-05-28 10:24, Kagamin wrote:

> Well, that's the point: it's a normal function.

But it's not.

-- 
/Jacob Carlborg