Will macros work with expressions?

Bill Baxter dnewsgroup at billbaxter.com
Mon Sep 3 16:18:50 PDT 2007


Robert Fraser wrote:
> Reiner Pope Wrote:
> 
>> Bill Baxter wrote:
>>> Xinok wrote:
>>>> Bill Baxter wrote:
>>>>> A question about the upcoming macros:
>>>>> Will they work for expressions as well as statements?
>>>>>
>>>>> The examples in WalterAndrei.pdf all show complete statements,
>>>>> like
>>>>>    macro foo(e) { e=3; }
>>>>>
>>>>> But will it be possible to have:
>>>>>    macro foo(e) { e+3 }
>>>>>
>>>>> I hope expressions will be allowed.  Not for things like e+3 but for 
>>>>> making local shortcuts where aliases don't cut it:
>>>>>
>>>>>    macro call_func( arg ) {
>>>>>       $this.some_member.a_really_long_named_template_member(arg);
>>>>>    }
>>>>>    ...
>>>>>    writefln(call_func(1));
>>>>>    writefln(call_func("hi"));
>>>>>
>>>>> And I'm sure there'd be any number of other uses for expression macros.
>>>>>
>>>  > I agree that macro expressions should be allowed. However, I think a
>>>  > better syntax would be:
>>>  >
>>>  > macro foo(e) = e + 3;
>>>  >
>>>
>>> I like that. But what about an expression with a few preliminary 
>>> statements setting up temp variables and such?
>>>
>>> --bb
>> If it's going to be "pasted" into the call-site, then how can that work? 
>> I imagine you'd have to set it up as a function call.
>>
>> Of course, a nicer solution is a syntax where (nearly) everything is an 
>> expression, like many functional languages.
>>
>>     -- Reiner
> 
> Walter discussed this during his talk I believe. Indeed, macros will
> do syntax-tree substitution and variable declarations are becoming
> expressions, so you'll be able to insert temporary variables, etc.

Variable declarations will become expressions!?  That's interesting.  I 
wonder what the scope will be for such things.

> My worry is that macros used inside expressions will not be able to
> contain statements. This is a shame, since this means that macros and
> function calls won't be interchangeable. Looks like macros will be
> slightly more powerful than their C counterparts, which I've never
> used.

I dunno about their "power", but At least they'll be significantly safer 
and more robust than their C counterparts.

--bb



More information about the Digitalmars-d mailing list