Here's what I'm trying to do.  I want to build a template which takes, as its first parameter, a type, and then takes one or more aliases to member names.  In other words, the user of the template would write something like this:

BEGIN CODE (that doesn't work)
	struct s
	{
		int x;
	}
	void main()
	{
		magic_template!(s, x);
	}
END CODE

However, I can't figure out how to do it.  Right now, I'm stumbling along with string mixins, as follows:

BEGIN CODE
	template foo(T,string member)
	{
	  T *of()
	  {
	    T *ret = new T;
	    mixin("ret." ~member~ "= 1;");
	    return ret;
	  }
	}

	struct s
	{
	  int x;
	}

	import std.stdio;
	void main()
	{
	  auto tmp = foo!(s,"x").of();
	  writefln(tmp.x);
	}
END CODE


Does anybody know of a more elegant way to do this?

Russell Lewis wrote:
> Here's what I'm trying to do.  I want to build a template which takes, as its first parameter, a type, and then takes one or more aliases to member names.  In other words, the user of the template would write something like this:
> 
> BEGIN CODE (that doesn't work)
>     struct s
>     {
>         int x;
>     }
>     void main()
>     {
>         magic_template!(s, x);
>     }
> END CODE
> 
> However, I can't figure out how to do it.  Right now, I'm stumbling along with string mixins, as follows:
> 
> BEGIN CODE
>     template foo(T,string member)
>     {
>       T *of()
>       {
>         T *ret = new T;
>         mixin("ret." ~member~ "= 1;");
>         return ret;
>       }
>     }
> 
>     struct s
>     {
>       int x;
>     }
> 
>     import std.stdio;
>     void main()
>     {
>       auto tmp = foo!(s,"x").of();
>       writefln(tmp.x);
>     }
> END CODE
> 
> 
> Does anybody know of a more elegant way to do this?

I think that's about as good as it gets right now.  You could eliminate the .of part by making foo a function template.  You can also do some interesting things by deducing the type from the "x" part:
   alias typeof(mixin("ret."~member)) X;

... or maybe you need to put the whole alias expression in a string. I'm not quite clear on what can and can't go into a mixin.

If that's not enough, try being more specific about what you are actually trying to do, and maybe someone can offer a better solution.

--bb

Bill Baxter wrote:
> If that's not enough, try being more specific about what you are actually trying to do, and maybe someone can offer a better solution.

I'm trying to build a parser library.  The syntax I'm experimenting with is:
	parse(output_type, <member names>...)
where the library figures out the type of each member and automatically calls the correct parse() function at the right time.  (The order in which you call the various member names determines the order in which the various nonterminals must show up in the file being parsed.)

I already have the mechanics of the parser library working, but it's not easy to use.  The point of the template is to auto-generate most of the client-side code.

Russell Lewis wrote:
> Bill Baxter wrote:
>> If that's not enough, try being more specific about what you are actually trying to do, and maybe someone can offer a better solution.
> 
> I'm trying to build a parser library.  The syntax I'm experimenting with is:
>     parse(output_type, <member names>...)
> where the library figures out the type of each member and automatically calls the correct parse() function at the right time.  (The order in which you call the various member names determines the order in which the various nonterminals must show up in the file being parsed.)
> 
> I already have the mechanics of the parser library working, but it's not easy to use.  The point of the template is to auto-generate most of the client-side code.

Ok.  So the literal "=1" part in your example would be replaced with a type specific parse function.

I think the direction you're going is the best you can hope for right now.  It's pretty darn decent, though, if you ask me.

--bb

Bill Baxter wrote:
> Ok.  So the literal "=1" part in your example would be replaced with a type specific parse function.

It's not relevant to the question, but I am so enthralled with my parser I just have to tell you about it. :)

I'm experimenting with a way to be able to parse ambiguous grammars while reducing the amount of copying required.  The problem with an ambiguous grammar is that you have a nonterminal of type foo, which has to parse bar and then baz.  It parses the bar first, and then tries to parse the baz; but if there are two possible parsings of baz, then you have to copy the foo struct and keep track of both.  It's doable when you have pointers, but when you are parsing arrays of elements and you ask yourself "I have 1000 elements so far...can I parse one more?" it gets hard, because you have to copy the entire array to a new location (keeping the old around) just in case.  Now imagine that maybe some of the elements of the array are ambiguous, too, just multiplying the combinations...

So what I'm experimenting with are producing "infill" delegates.  The parse function for a given nonterminal doesn't actually produce the value type which summarizes the information...it instead produces a delegate which, if it is ever called, will fill a type.  So no actual parse tree is produced until you get some overall "whole file parsed" delegate.  You can then allocate the struct for the root of the parse tree, call the infill, and it builds the tree for you.  Arrays work the same way...the infill delegate for 1000-element array just calls the infill delegate for the 999-element array, and then the infill delegate for the last element.

The reason that this is nice is that you never copy stuff around...you simply pass around delegates which have the *potential* to build parse trees.  Parsings that you explore which later die simply mean that certain trees of delegates become garbage.

Right now, I have most of the common-code mechanisms in place, and I'm starting to actually use it to parse real things.  Which is why I finally had to address the client-side code...it's quite ugly, even though I've worked hard with templates to automate things.

What I don't know, yet, is whether or not I can make it fast enough.  I make heavy use of closures and currying (which makes the code more elegant than it would have been otherwise), but I may just be trading one overhead for another.  Plus, the heavy cost of function calls may make all of those nested infill delegates impractical.  We'll see.