Overlapping functionality: IFTI, templates, is-expressions

[BCS]

Russell Lewis wrote:
> BCS wrote:
> 
>> Russell Lewis wrote:
> 
> 
> Thanks for the example code.  I'll look it over soon, but right now I 
> have to do my real job. :(
> 
> I do have one response and one more question, though...
> 
> (huge snip)
> 
>>> Ofc, if you have a parser library which is functional even if it's a 
>>> little clunky, then hopefully you could use that library to scan 
>>> input strings, build parse trees, and then generate parsers from 
>>> that. :)
>>
>>
>> I don't follow: Are you talking about parsing at run time or compile 
>> time?
> 
> 
> Both, actually.  My hope is to build a a parser library which is good 
> for runtime parses, but which also, with CTFE and a string-to-template 
> compile-time lexer, could be used to parse the actual grammar code that 
> people give me as input.  That is:
> 
>     stringInput -> compile-time-lexer -> myLibrary -> CTFE
>                 -> parse tree of user's grammar
>                 -> code which uses my library -> generated parser
> 
> We'll see if it works...
> 

you are ambitious! You might run into some issues with the CTFE retuning 
parsed structures. IIRC it's very restrictive about what it will return.

>>> Also, how good are you at handling ambiguous grammars?
>>
>>
>> It doesn't care. It work by matching the first match given so if there 
>> is ambiguity, it won't know and will still produce something as output.
> 
> 
> I should have also asked about lookahead.  I didn't, because I view 
> lookahead & ambiguity as the same thing in my parser. :)
> 
[...]
> 
> So: can you handle arbitrary lookahead?  Or do you, like Bison, make a 
> one-time choice of "reduce or shift" and then you're stuck with it?

Mine is a recursive decent LL parser that works by way of "assume this 
is one of those and if not back-out and try again". So it is LL(*).