Is there a template syntax for alias-of-member?
webmaster at villagersonline.com
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 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.
More information about the Digitalmars-d-learn