On 2013-11-06 21:33, Timothee Cour wrote:

> How about parametrizing the escape string:
> r{var=@a} //@ by default
> r{@}{var=@a} //same as above
> r{$}{var=$a} //same as above

Looks like this is getting quite complicated.

-- 
/Jacob Carlborg

On 2013-11-06 23:48, Timothee Cour wrote:

> As I mentioned in my OT, this is what I already have implemented ("I've
> actually already implemented this feature via a mixin, and find it
> extremely useful, but ... "); and I did take care of proper escaping,
> etc. I am using it extensively, however the requirement for using a
> mixin makes things uglier than they should:
>
> * cryptic ctfe error msgs upon wrong variable names
> * mixin can't be used in UFCS chains; additional () nesting
> to the point that I only use it in cases where the alternative is uglier.
> * potentially more strain on ctfe
> * mixins in general should be used sparingly
>
> Sure we can use existing mixins to fill this need, but to me this is
> exactly the same as the situation with lambda literal syntax:
>
> a=>a*2
> instead of
> (a){return a*2;}
>
> or lazy parameters:
> void fun(lazy string a)
> vs:
> void fun(string delegate() a)
>
> A little of syntax sugar can provide huge benifits.
> It's use case would apply to all assert error messages, DSLs etc.

I agree with you, but I rather have a more general solution. That is, AST macros.

-- 
/Jacob Carlborg

On Thu, Nov 7, 2013 at 2:27 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-11-06 23:48, Timothee Cour wrote:
>
>  As I mentioned in my OT, this is what I already have implemented ("I've
>> actually already implemented this feature via a mixin, and find it extremely useful, but ... "); and I did take care of proper escaping, etc. I am using it extensively, however the requirement for using a mixin makes things uglier than they should:
>>
>> * cryptic ctfe error msgs upon wrong variable names
>> * mixin can't be used in UFCS chains; additional () nesting
>> to the point that I only use it in cases where the alternative is uglier.
>> * potentially more strain on ctfe
>> * mixins in general should be used sparingly
>>
>> Sure we can use existing mixins to fill this need, but to me this is exactly the same as the situation with lambda literal syntax:
>>
>> a=>a*2
>> instead of
>> (a){return a*2;}
>>
>> or lazy parameters:
>> void fun(lazy string a)
>> vs:
>> void fun(string delegate() a)
>>
>> A little of syntax sugar can provide huge benifits.
>> It's use case would apply to all assert error messages, DSLs etc.
>>
>
> I agree with you, but I rather have a more general solution. That is, AST macros.
>
>
I would love to have AST macros too, but how do they help for the problem at hand? (eg use cases in OT + DSL). Like others mentioned, the feature is not crazy, it is present in most languages.




> --
> /Jacob Carlborg
>

On 2013-11-07 12:05, Timothee Cour wrote:

> I would love to have AST macros too, but how do they help for the
> problem at hand? (eg use cases in OT + DSL). Like others mentioned, the
> feature is not crazy, it is present in most languages.

If AST macros worked like my vision [1] then it can be done by doing something like this. The declaration of the macro would look like this:

macro interpolate (Context context, Ast!(string) str)

* Scan "str" for occurrences of $variableName and $(expression) or whatever syntax is chosen

* Replace all occurrences with "%s"

* Create the following AST:

format(replacedStr, variableName, expression);

Use it like:

int a = 3;
int b = 4;

auto str = interpolate("a=$a b=$b");

Will generate the same AST as:

auto str = format("a=%s b=%s", a, b);

[1] https://dl.dropboxusercontent.com/u/18386187/ast_macros.html

-- 
/Jacob Carlborg