> On 10 Nov 2018, at 13:51, Uxio Prego <uxio.pr...@gmail.com> wrote: > > Alright, but
OK, let's hear! >> 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. An implementation detail to be aware of is that if negative numbers are allowed as tokens, then 3-2 will parse as 3 followed by -2, not as a subtraction. So therefore, it may be better to having only positive numbers, not negative, and implement unary operator- and operator+, which is why C++ has them. So you may not be able to escape having some name overloading. > 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. Have a look at the C++ operator precedence table [1]. You might try to squeeze in the user defined operators at some point in the middle. 1. https://en.cppreference.com/w/cpp/language/operator_precedence > 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. In Haskell, it is a Monad operator, C++ does not have that. :-) The Haskell interpreter Hugs has a file Prelude.hs which defines a lot of prelude functions in Haskell code. But Haskell has only 10 precedence levels, which is a bit too little. > 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. It is good to think it through before implementing it. Bison makes it easy to define a compile time grammar, making it easy to test it out. _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
