Re: dlang: initial changes to run the calc tests on it

[H. S. Teoh]

On Thu, Feb 28, 2019 at 10:19:02PM +0100, Akim Demaille wrote:
> Hi HS!
> 
> > Le 28 févr. 2019 à 07:32, H. S. Teoh <address@hidden> a écrit :
[...]
> > ungetc is a truly nasty hack of an API in C; is it really necessary
> > to support that?
> 
> Certainly not!  I'm merely trying to get a scanner to feed our
> parsers with tokens, and mimicking the C API is all my knowledge
> of D allows me to do...

OK, good. :-)


[...]
> > What I'd do is to templatize CalcLexer on an arbitrary input range
> > of chars, and leave the specifics of binding to a File (or whatever
> > else, like a string in a unittest) to the caller. And I wouldn't
> > bother with using class inheritance at all, since I can't envision
> > we'd ever need to swap in multiple lexers to the same parser.  So
> > something like this:
> 
> This is already quite advanced compared to the current state of the
> D skeleton.  What I'm looking for is a simple scanner that works with
> what we have.  For instance below I tried to import your suggestion
> into examples/d/calc.y, but it does not work.  Could you help me
> make it work?  Just put it in examples/d/ and run "make check".
[...]

Try the attached version of calc.y instead.

Eventually I think we should move away from the Lexer class, and have
the generated parser accept any type that has the required interface
(yylex(), semanticVal(), etc.).  In the ideal case, the lexer would
simply be a struct that wraps around an arbitrary input range of
characters.  In order to make things work with the current code, though,
I conceded to make CalcLexer a class that implements Lexer.  We can
change that when we get around to moving away from lexer classes.


T

-- 
Many open minds should be closed for repairs. -- K5 user

calc.y
Description: Text document