www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - "Hiding" the mixin keyword?

reply renoX <renosky free.fr> writes:
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
Feb 23 2007
parent reply Reiner Pope <xxxx xxx.xxx> writes:
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
Feb 23 2007
parent reply renoX <renosky free.fr> writes:
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
Feb 24 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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. ;)
Feb 24 2007
parent reply renoX <renosky free.fr> writes:
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
Feb 24 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Feb 24 2007