Hello,

I implemented a format string template, but my problem is that calling it looks like this:
mixin(putf!("Should be 31: %d{x+y+1}\n"));

Here's putf definition:
template putf(A...)
{
	const char[] putf = "writef(" ~ Fmt!(A) ~ ");";
	//static pragma(msg, "putf result is'"~putf~"'");
}
Fmt being the template which does the real work of parsing the format string.

What I would like is a way to 'hide' the mixin keyword, is-it possible to put into the template so that the result would look like:
putf!("Should be 31: %d{x+y+1}\n"); ?

Maybe with a static wrapper function?
Or is-it impossible?

All my trials failed so far..

Thanks for your help,
renoX

I don't think this is possible, but it certainly seems worthwhile to support more advanced features through a standard function-call interface.

Andrei has been nagging Walter about this and making suggestions, so I suppose we can hope it will be implemented sometime soon.


renoX wrote:
> What I would like is a way to 'hide' the mixin keyword, is-it possible to put into the template so that the result would look like:
> putf!("Should be 31: %d{x+y+1}\n"); ?

I don't think it would be too hard to work out the details. What I can think you might need is the following:

 1. The ability to specify that certain parameters in the list must be compile-time constants, and the ability to overload by this.
 2. Some kind of interface at the declaration site that specifies that the return value of a given function be mixed into the code instead of just treated as a value

The first one could look like this:

> 
> RegExpMatch matchRegexp(static char[] compileTimePattern, char[] text){...} // Parses the pattern at compile time
> RegExpMatch matchRegexp(char[] runtimePattern, char[] text) {...} // Parses it at runtime

This would mean a library user wouldn't have to call a different function to get the compile-time version than to get the runtime version.

The second would just involve adding some kind of modifier to a template declaration, like the following:

> mixin template putf(A...)
> {
>     const char[] putf = ...;
> }
> 
> // Instantiated like:
> 
> putf!("stuff");
> 
> or
> 
> mixin char[] putf(static char[] pattern)
> {
>     ...
>     return generatedCode;
> }
> 
> // Instantiated like:
> 
> putf("pattern %d{foo}");
> 
> // with the return value mixed in


This could also give you cool things, like the ability to mimic tuple's compile-time indexing and make your own tuple wrapper:

> 
> struct MyTuple(A...)
> {
>     A data;
>     typeof(A[i]) opIndex(static size_t i)
>     {
>         return data[i];
>     }
> }



Cheers,

Reiner

Reiner Pope a écrit :
> I don't think this is possible, but it certainly seems worthwhile to support more advanced features through a standard function-call interface.
> 
> Andrei has been nagging Walter about this and making suggestions, so I suppose we can hope it will be implemented sometime soon.

OK, thanks for your help, I'll stop wasting my time trying to get rid of the mixin() at the call site..
It's weird though: Reiner Pope in its 'Mixin demo: associative array initializers (with support for comments)' (digitalmars.D) did a mixin inside the associative array initialisation template, hiding the mixin, but I don't manage to do the same things.

> 
> renoX wrote:
>> What I would like is a way to 'hide' the mixin keyword, is-it possible to put into the template so that the result would look like:
>> putf!("Should be 31: %d{x+y+1}\n"); ?
> 
> I don't think it would be too hard to work out the details. What I can think you might need is the following:

I'm not sure what you're saying here, but for the implementation look for 'Improvement on format strings, take two.' in digitalmars.D.

It treats differently const and non-const char[] thanks to a tip provided by mario pernici.

renoX
> 
>  1. The ability to specify that certain parameters in the list must be compile-time constants, and the ability to overload by this.
>  2. Some kind of interface at the declaration site that specifies that the return value of a given function be mixed into the code instead of just treated as a value
> 
> The first one could look like this:
> 
>>
>> RegExpMatch matchRegexp(static char[] compileTimePattern, char[] text){...} // Parses the pattern at compile time
>> RegExpMatch matchRegexp(char[] runtimePattern, char[] text) {...} // Parses it at runtime
> 
> This would mean a library user wouldn't have to call a different function to get the compile-time version than to get the runtime version.
> 
> The second would just involve adding some kind of modifier to a template declaration, like the following:
> 
>> mixin template putf(A...)
>> {
>>     const char[] putf = ...;
>> }
>>
>> // Instantiated like:
>>
>> putf!("stuff");
>>
>> or
>>
>> mixin char[] putf(static char[] pattern)
>> {
>>     ...
>>     return generatedCode;
>> }
>>
>> // Instantiated like:
>>
>> putf("pattern %d{foo}");
>>
>> // with the return value mixed in
> 
> 
> This could also give you cool things, like the ability to mimic tuple's compile-time indexing and make your own tuple wrapper:
> 
>>
>> struct MyTuple(A...)
>> {
>>     A data;
>>     typeof(A[i]) opIndex(static size_t i)
>>     {
>>         return data[i];
>>     }
>> }
> 
> 
> 
> Cheers,
> 
> Reiner

renoX wrote:
> It's weird though: Reiner Pope in its 'Mixin demo: associative array initializers (with support for comments)' (digitalmars.D) did a mixin inside the associative array initialisation template, hiding the mixin, but I don't manage to do the same things.

Looks like he hid the mixin() in a templated function call, using property syntax to remove the trailing ().
I'm pretty sure that means he can't support variables in the initializers, nor expressions containing variables.
It would seem these are quite important for a (runtime) string formatter though. ;)

Frits van Bommel a écrit :
> renoX wrote:
>> It's weird though: Reiner Pope in its 'Mixin demo: associative array initializers (with support for comments)' (digitalmars.D) did a mixin inside the associative array initialisation template, hiding the mixin, but I don't manage to do the same things.
> 
> Looks like he hid the mixin() in a templated function call, using property syntax to remove the trailing ().
>
> I'm pretty sure that means he can't support variables in the initializers, nor expressions containing variables.
> It would seem these are quite important for a (runtime) string formatter though. ;)

My string formatter works at compile-time not runtime, but it generates an expression which contain runtime variable..

So I guess that's why I need to have a mixin keyword at the call site, too bad.

Thanks for your help.

renoX

renoX wrote:
> Frits van Bommel a écrit :
>> renoX wrote:
>>> It's weird though: Reiner Pope in its 'Mixin demo: associative array initializers (with support for comments)' (digitalmars.D) did a mixin inside the associative array initialisation template, hiding the mixin, but I don't manage to do the same things.
>>
>> Looks like he hid the mixin() in a templated function call, using property syntax to remove the trailing ().
>  >
>> I'm pretty sure that means he can't support variables in the initializers, nor expressions containing variables.
>> It would seem these are quite important for a (runtime) string formatter though. ;)
> 
> My string formatter works at compile-time not runtime, but it generates an expression which contain runtime variable..

That's what I meant.

> So I guess that's why I need to have a mixin keyword at the call site, too bad.

Yep.

> Thanks for your help.

No problem.