Alright, but > On 8 Nov 2018, at 23:37, Hans Åberg <haber...@telia.com> wrote: > >> On 8 Nov 2018, at 22:34, Uxio Prego <uxio.pr...@gmail.com> wrote: >> >>> [...] >> >> The example and explanation are worth a thousand words, >> thank you very much. So I use a simple grammar like that, and >> the stack data structures, and if necessary feed the lexer back >> with data from the parser once the user requests some infix >> operators. > > It is only if you want to have a prefix and an infix or postfix operator with > the same name, like operator- or operator++ in C++, that there is a need for > handshake between the lexer and the parser, and it suffices with a boolean > value that tells whether the token last seen is a prefix operator. Initially > set to false, the prefix operators set it to true in the parser, and all > other expression tokens set it to false. Then, when the lexer sees an > operator that can be both a prefix and an infix or postfix, it uses this > value to disambiguate. I leave it to you to figure out the cases, it is not > that hard, just a bit fiddly. :-) >
Yeah, but e.g. I don't plan to define ++ as operator at all, even though I would want any users wanting it to be able to configure so. I guess this would require, either predefining it even with no actual core semantic; or providing the parser-to-lexer feedback, and eventually to replace a current vanilla and clean flex lexer for something else, and/or writing a lot of ugly hack in it. Now think that the ++ operator has completely different meaning from a C++ perspective than from a Haskell perspective. Repeat for the ** operator, which exists in Python or Haskell but not (or if it does exist, for sure they are not very popular) in languages like C++ or Java. Some languages provide a // operator, etc. So predefining is not a good solution I would say. Anyway this is just thinking about the ultimate possibilities that in my opinion some abstract extensible spec should try to provide, or at least foresee, but I don't prioritize to fully implement. _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison