Hi Francesco, Please keep the list (and the archive!) in CC.
> Le 10 févr. 2020 à 10:00, lagfra <[email protected]> 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!
