- 250 * 1.5 is not the same as 250 * 1.5
Locked
12
12
 
|
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25 while -250 * 1.5 return 375 stef |
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
debug it on the first one gives "MNU: receiver of "doSemanticAnalyisIn:" is nil. Weird.On Wed, Sep 23, 2015 at 8:40 AM, stepharo <[hidden email]> wrote: Hi guys |
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
RBParser parseExpression: '- 250 * 1.5' => Answers RBMessageNode(*1.5 * 1.5) Second expression looks correct. Hence RBParser bug. 2015-09-23 23:42 GMT+02:00 [hidden email] <[hidden email]>:
|
|
|
RBParser parseExpression: '-250 * 1.5' => "RBMessageNode(-250 * 1.5)"
RBParser parseExpression: '- 250 * 1.5' => "RBMessageNode(*1.5 * 1.5)" RBParser parseExpression: '250 * -1.5' => "RBMessageNode(250 * -1.5)" RBParser parseExpression: '250 * - 1.5' => MNU RBToken>>realvalue. RBParser parseExpression: '-250' => "RBLiteralValueNode(-250)" RBParser parseExpression: '- 250' => MNU RBToken>>realvalue. So how significant should be the space between the negative sign and its number? cheers -ben On Thu, Sep 24, 2015 at 6:34 AM, Clément Bera <[hidden email]> wrote: > RBParser parseExpression: '- 250 * 1.5' => Answers RBMessageNode(*1.5 * > 1.5) > > Second expression looks correct. > > Hence RBParser bug. > > 2015-09-23 23:42 GMT+02:00 [hidden email] <[hidden email]>: >> >> debug it on the first one gives "MNU: receiver of "doSemanticAnalyisIn:" >> is nil. >> >> Weird. >> >> On Wed, Sep 23, 2015 at 8:40 AM, stepharo <[hidden email]> wrote: >>> >>> Hi guys >>> >>> I think that this is quite bad that >>> - 250 * 1.5 returns -2.25 >>> >>> while >>> >>> -250 * 1.5 return 375 >>> >>> stef >>> >> > |
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
> - 250 * 1.5 returns -2.25 why is this valid syntax? On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <[hidden email]> wrote: RBParser parseExpression: '-250 * 1.5' => "RBMessageNode(-250 * 1.5)" |
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
2015-09-24 8:19 GMT+02:00 Peter Uhnák <[hidden email]>:
I don't know if this is valid syntax (I always wondered that there is one place in PointTest, that is not compilable with old compiler but compiles fine with opal). But the error happens in RBParser>>#parseNegatedNumber. If a #- is recognized, it tests if a literalnumber follows (but from the token stream, that is, the spaces are ignored). Now the real bug is, that we do two "steps" and concstruct a new literalvaluenode from the now following tokens. RBParser parseExpression:'- 2' -> throws an error, because no following tokens RBParser parseExpression:'- 2 * 3' -> works but actually duplicates the two last tokens "*3 *3. and some funny other things '- 2@1' -> '-1@1' instead, we should: save sign and number token do the two steps construct the literalvaluenode fromt the two saved tokens: parseNegatedNumber |tokenSign tokenNumber| (self nextToken isLiteralToken not or: [ self nextToken realValue isNumber not ]) ifTrue: [ ^ self parserError: 'The ''-'' prefix works only for literal numbers (use #negated instead)' ]. tokenSign := currentToken. self step. tokenNumber := currentToken. self step. ^ self literalValueNodeClass value: tokenNumber realValue negated start: tokenSign start stop: tokenNumber stop source: tokenSign value, tokenNumber source. But only if we want to support spaces between sign and number tokens. BTW, if we use "-2" without space, parseNegatedNumber isn't even called, I guess the scanner already creates a single (negated)number token.
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
In reply to this post by Peter Uhnak
2015-09-24 8:19 GMT+02:00 Peter Uhnák <[hidden email]>:
It should not. RBParser bug. This is not valid Smalltalk syntax. As Ben showed similar cases raise an error but this one generate incorrect compiledMethod instead.
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
A space used to be accepted between minus sign and number in old versions of Squeak compiler (before 2010) But I doubt this was decided on purpose.IMO it was more a side effect of the implementation, which had messy corners (the fact that the tokenizer did produce two tokens $- and positive number) I would add that this was undocumented, dialect specific, and a false good idea letting newbies think that they can use unary prefixed operators... ------------------------------------------------------- http://source.squeak.org/trunk/Compiler-nice.120.mcz ==================== Summary ==================== Name: Compiler-nice.120 Author: nice Time: 23 February 2010, 5:14:44.049 pm UUID: 9429cc05-281b-484e-94c2-bd0baf4f5230 Ancestors: Compiler-nice.119 Authorize - at any position in binary selectors (like VW 7.7) See http://bugs.squeak.org/view.php?id=3616 Address the problem of compiling 1@-2 with following strategy: If compiler is non interactive, then compile with backward compatibility 1 @ (-2). If compiler is interactive, propose a menu to disambiguate and insert a proper space. 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... I didn't do anything to support this vicious Squeakism, and by now the semantics are change. 2015-09-24 9:25 GMT+02:00 Clément Bera <[hidden email]>:
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
Oh, and I suspect an instability in the numbering of squeak-dev archive... The reference thread is (today) http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/103684.html2015-09-24 11:39 GMT+02:00 Nicolas Cellier <[hidden email]>:
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
Then, given that negative numbers are correctly tokenified by the RBParser, I would remove that logic in Pharo's RBParser.
(From a front-end implementor point of view, I also would have no issue with someone specifying a negative literal as - (\s)* [0-9]+ either. There is so much silliness in your average language front-end anyway). What is the state of RBParser in Squeak about that? Thierry 2015-09-24 12:03 GMT+02:00 Nicolas Cellier <[hidden email]>:
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
2015-09-24 13:23 GMT+02:00 Thierry Goubier <[hidden email]>:
My grief was the interpretation of literal arrays: #(1 - 2) is currently not #(1 -2), so if space is gobbled at tokenization, that's a semantic shift... Do we want to keep #(1 - 2) or shall we force some more pedantic #(1 #- 2)?
RBParser is not in trunk, it's an add-on. No idea which/where is the latest Squeak-compatible version...
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
2015-09-24 14:01 GMT+02:00 Nicolas Cellier <[hidden email]>:
Fair point. I'd guess that, on average, people have a good chance of guessing #(1 - 2) wrong ;) but I'd keep the no space between - and the number, just for the fact it makes documentation clearer.
Oh, I would have expected RB to be included in Squeak trunk. Good to know :) Thierry
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
In reply to this post by Nicolas Cellier
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
In reply to this post by Nicolai Hess
Le 24/09/2015 09:11, Nicolai Hess a écrit :
> > > 2015-09-24 8:19 GMT+02:00 Peter Uhnák <[hidden email] > <mailto:[hidden email]>>: > > > - 250 * 1.5 returns -2.25 > > why is this valid syntax? > > > > I don't know if this is valid syntax (I always wondered that there is > one place in PointTest, that is not compilable with old compiler but > compiles > fine with opal). > But the error happens in > RBParser>>#parseNegatedNumber. > If a #- is recognized, it tests if a literalnumber follows (but from the > token stream, that is, the spaces are ignored). > Now the real bug is, that we do two "steps" and concstruct a new > literalvaluenode from the now following tokens. > RBParser parseExpression:'- 2' -> throws an error, because no following > tokens > RBParser parseExpression:'- 2 * 3' -> works but actually duplicates the > two last tokens "*3 *3. > and some funny other things '- 2@1' -> '-1@1' Another one I found in the tests: would you expect RBParser parseExpression: '# 1 = 1' To be the same thing as '#1 = 1' ? Thierry |
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
Would not expect that to be the case :) Doru On Thu, Sep 24, 2015 at 10:39 PM, Thierry Goubier <[hidden email]> wrote: Le 24/09/2015 09:11, Nicolai Hess a écrit : |
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
In reply to this post by Thierry Goubier
2015-09-24 22:39 GMT+02:00 Thierry Goubier <[hidden email]>: Le 24/09/2015 09:11, Nicolai Hess a écrit : I tested this in squeak and it seems that #1 isn't allowed as symbol, the only way to use a digit as symbol is #'1' (is this defined in smalltalks syntax defintion?) -> Parsing '#' has to be fixed too.
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
Note for ref on the original point:
ANSI Smalltalk allow for space between - and the number token. Squeak is then non A For the new point: ANSI Smalltalk does not allow for space between # and the selector, or between # and the quoted string. Should be an easy fix. Marcus, how do we should validate RBParser changes? Reparse all the code in the image and compares ASTs? Thierry 2015-09-25 8:52 GMT+02:00 Nicolai Hess <[hidden email]>:
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
2015-09-25 9:53 GMT+02:00 Thierry Goubier <[hidden email]>:
Note to self for later: RBScanner>>#scanLiteral call stripSeparators before checking $# and calling again scanLiteral, which means it has a good chance of calling stripSeparators twice when dealing with the beginning of a symbol. Thierry
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
In reply to this post by Thierry Goubier
2015-09-24 22:39 GMT+02:00 Thierry Goubier <[hidden email]>: Le 24/09/2015 09:11, Nicolai Hess a écrit : And another one: #t = ##t "-> true" I thnk ##t should be allowed.
|
Re: - 250 * 1.5 is not the same as 250 * 1.5
|
|
2015-09-25 11:01 GMT+02:00 Nicolai Hess <[hidden email]>:
I would allow it if it doesn't impact the code. At the moment, what I see is that ## is allowed because #scanLiteral is recursive for symbols... sort of side effect of the current implementation. If correcting makes it non-recursive, I won't introduce a special check to allow ## and ### and ####. ## has a special meaning in some smalltalks (Dolphin?). Removing ## would make porting Dolphin code (SmaCC, for example) harder. Thierry
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |