Is there a template syntax for alias-of-member?

Russell Lewis webmaster at
Fri Mar 7 11:33:37 PST 2008

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 

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 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 
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'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.

More information about the Digitalmars-d-learn mailing list