2009/10/30 erik quanstrom <quans...@quanstro.net>: >> Python handles correctly e.g. 2-----7, 2+-+-7, 2+++-7,... >> C-compiler that I use in my linux, gcc, is ok for a+-b and a-+b, also >> for a+-+-b, but not for a++b or a--b or any alike. > > you're confusing tokens and productions. the c tokenizer > has the following rules > -- -> DEC > ++ -> INC > + -> PLUS > - -> MINUS > > therefore the string "a++b" can't be valid, since the tokens > the parser sees are "a" INC "b". that's not kosher c. way > back when in primoridal c, there were no seperate tokens > for INC and DEC, they were productions in the parser and > goofiness like you describe was allowed.
Well, for exactly this reason I said I wouldn't produce INC & DEC tokens in the lexer. a++b would then be translated by the parser to a + (+b), since this would be the only sensible meaning (a INC b doesn't work). The same would be for any NUMBERS. These can't be ++ or --; there the + & - would only be unary +,- operators. This would give sence to anything like 2++7, 2--+7, where only numbers appear. I formerly thought that INC & DEC could be somehow elegantly reconciled even with operations on variables (like a++b above). But a+++b (where we would have to decide), and more importantly --b shows it can't be done. This took me some time to realize. Thus for NUMBERS the goal of reading complicated things could be achieved. For variables not, unless INC and DEC disappear (they are not in python or maxima). Now, the question is whether it's worth changing the behaviour for number expressions... This is the analysis for which I was looking. That's the reason I started this thread. It's only after I know the details that I decide what to do. > also, this is a very long discussion for a one-line fix. There are much longer much less fruitful (for me) threads all around. And neither you explained, just submitted a patch. Thanks for it, but first I needed to know WHY it is that I can't read expressions that are ok elsewhere. Thanks Ruda
