Re: Regarding Bison 3.5 D backend

[Akim Demaille]

Hi Francesco,

Please keep the list (and the archive!) in CC.

> Le 10 févr. 2020 à 10:00, lagfra <address@hidden> a écrit :
> 
> Hi Akim,
> 
> please excuse me for the late reply, I didn't mean to keep you waiting but I'm
> finishing up my master thesis right now and I had little spare time these 
> days.
> 
> I managed to build Bison and run the test suite (make check), I've followed 
> the
> instructions from the README-hacking file.

Which is a good starting point!

> I didn't have time to extend the D
> example substantially, but I've done some experiments in modifying 
> `examples/d/calc.y`.
> I was mainly interested in checking which D constructs are supported by the 
> Bison
> preprocessor, especially function attributes such as `pure`,`@nogc`,`@safe` 
> and
> type qualifiers (`const`,`immutable`).

Excellent!  I'm interested in producing good quality code, not just
correct code.

> In my opinion the example looks good but
> it could be improved to match the D style a little bit:
> 
> - It would be nice to treat the whole lexer as a range to support
>  D's iterative constructs such as `foreach` and `std.algorithm : each`, in a
>  similar way as it is for the input stream. This is useful since the range
>  abstraction makes it quite elementary to support arbitrarely qualified
>  functions and types. Transforming the Lexer class in a range-based class is a
>  matter of adding the empty() and popFront() attributes. Pushing this approach
>  further, the whole parsing chain could be used lazily, yet I'm not sure
>  wether this would be useful or not and if the lazy approach would be
>  compatible with the way Bison currenly handles lexing / parsing.

I have no idea what you are referring to here, so I'll be very happy
to wait for you to finish your thesis and to submit patches :)


> - Avoiding the usage of heap-allocating functions is usually preferred (and 
> can
>  be checked by marking code as @nogc and @safe). The main issue in this sense 
> is
>  the usage of `joiner` on a @system level range `file.byChunk` (see
>  calc.y:60-69).

That's really code in the example itself.  I'm happy to improve it,
but I'm more worried with the generated code.

> It would be nice to buffer the dchars read directly by copying
>  them or mapping them to another dchar[] range before forwarding them to the
>  overload of `calcLexer`.
> 
> These considerations are of little impact on the actual backend 
> implementation since
> they concern what I believe is called "user-defined" code in yacc/bison's 
> lingo.
> For the upcoming days my plans are to extend the calculator example to
> support evaluation of arbitrarely long boolean formulas, thus adding equality
> and inequality operators and unary / binary boolean connectors.

You should really read the generated code and see if it matches your
expectations.

> I hope this (fairly easy) task gives me a feel of what is to be improved in 
> the
> D backend, though it could be helpful to know what to look for, meaning: which
> are the issues or the shortcomings of the skeleton you would like to 
> concentrate
> on?

For a start I don't like the use of %union.  We should add support
for api.value.type variant or union.  The question is how does
D behave when storing non plain old data types in a union.  See
the examples about api.value.type in the documentation to see what
I mean.

Cheers!