- 250 * 1.5 is not the same as 250 * 1.5
Hi guys I think that this is quite bad that - 250 * 1.5 returns -2.25 while -250 * 1.5 return 375 stef
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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of "doSemanticAnalyisIn:" is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of "doSemanticAnalyisIn:" is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
- 250 * 1.5 returns -2.25
why is this valid syntax? On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of "doSemanticAnalyisIn:" is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 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' 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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
> - 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
Would not expect that to be the case :) Doru On Thu, Sep 24, 2015 at 10:39 PM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
> - 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
-- www.tudorgirba.com "Every thing has its own flow"
2015-09-24 22:39 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
> - 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' ?
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.
Thierry
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 <nicolaihess@web.de>:
2015-09-24 22:39 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
> - 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' ?
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.
Thierry
2015-09-25 9:53 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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.
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
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 <nicolaihess@web.de>:
2015-09-24 22:39 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
> - 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' ?
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.
Thierry
On 25 Sep 2015, at 09:53, Thierry Goubier <thierry.goubier@gmail.com> wrote:
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?
Yes, I think so⦠it would of course be better to have a larger scale regression test suite, but for now ârecompiling the imageâ is the thing we do to check the compiler Marcus
2015-09-25 13:01 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
On 25 Sep 2015, at 09:53, Thierry Goubier <thierry.goubier@gmail.com> wrote:
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?
Yes, I think so⦠it would of course be better to have a larger scale regression test suite, but for now ârecompiling the imageâ is the thing we do to check the compiler
Ok. My issue was a kind of versionning effect on the parser, and a process like: - recover and store all asts for all methods - apply a change to RBParser - reparse all methods one by one and compare ASTs with previous We have good GUI tools for manipulating packages, but sometimes I'd like to have a branch concept inside the image which says: - revert to master, - do something, - switch to branch (and load your changes), - continue something to validate Thierry
Marcus
Le 25/09/2015 13:01, Marcus Denker a écrit :
On 25 Sep 2015, at 09:53, Thierry Goubier <thierry.goubier@gmail.com> wrote:
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?
Yes, I think so⦠it would of course be better to have a larger scale regression test suite, but for now ârecompiling the imageâ is the thing we do to check the compiler
Reparsing the whole image shows 7 uses of # <space> something and #number. Thierry
Marcus
2015-09-24 22:39 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
> - 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' ?
And another one: #t = ##t "-> true" I thnk ##t should be allowed.
Thierry
2015-09-25 11:01 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:
2015-09-24 22:39 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>:
> - 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' ?
And another one: #t = ##t "-> true"
I thnk ##t should be allowed.
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
Thierry
I would keep ## if in the future we need a new syntactic sugaring construct. Le 25/9/15 09:01, Nicolai Hess a écrit :
2015-09-24 22:39 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com> <mailto:i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>>:
> - 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' ?
And another one: #t = ##t "-> true"
I thnk ##t should be allowed.
Thierry
Le 25/09/2015 19:35, stepharo a écrit :
I would keep ## if in the future we need a new syntactic sugaring construct.
Why keep it if it is easy to add once you know you need it? For now, this code allows things like: RBParser parseExpression: '#####################################t' Note on all those funny symbol syntaxes: formatting will get rid of them. Another fun syntax example: RBParser parseExpression: '#" I am a quite long comment" t' Thierry
Le 25/9/15 09:01, Nicolai Hess a écrit :
2015-09-24 22:39 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák <<mailto:i.uhnak@gmail.com>i.uhnak@gmail.com <mailto:i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>>:
> - 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' ?
And another one: #t = ##t "-> true"
I thnk ##t should be allowed.
Thierry
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
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... There is no such thing in the language. Oh, and this even has changed in Squeak a few years ago: ------------------------------------------------------- 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 <bera.clement@gmail.com>:
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
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.html 2015-09-24 11:39 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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... There is no such thing in the language.
Oh, and this even has changed in Squeak a few years ago:
-------------------------------------------------------
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 <bera.clement@gmail.com>:
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
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 < nicolas.cellier.aka.nice@gmail.com>:
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.html
2015-09-24 11:39 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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... There is no such thing in the language.
Oh, and this even has changed in Squeak a few years ago:
-------------------------------------------------------
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 <bera.clement@gmail.com>:
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
2015-09-24 13:23 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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).
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)?
What is the state of RBParser in Squeak about that?
RBParser is not in trunk, it's an add-on. No idea which/where is the latest Squeak-compatible version...
Thierry
2015-09-24 12:03 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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.html
2015-09-24 11:39 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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... There is no such thing in the language.
Oh, and this even has changed in Squeak a few years ago:
-------------------------------------------------------
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 <bera.clement@gmail.com>:
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
2015-09-24 14:01 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2015-09-24 13:23 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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).
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)?
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.
What is the state of RBParser in Squeak about that?
RBParser is not in trunk, it's an add-on. No idea which/where is the latest Squeak-compatible version...
Oh, I would have expected RB to be included in Squeak trunk. Good to know :) Thierry
Thierry
2015-09-24 12:03 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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.html
2015-09-24 11:39 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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... There is no such thing in the language.
Oh, and this even has changed in Squeak a few years ago:
-------------------------------------------------------
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 <bera.clement@gmail.com>:
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 < bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be :
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
Hi Nicolas, On Thu, Sep 24, 2015 at 5:01 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2015-09-24 13:23 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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).
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)?
We should keep #(1 - 2) provided it is interpreted as #(1 #'-' 2). The # tags are noisy (if not ugly) and have never been necessary for literal symbols inside arrays. -2 is quite different from - 2. Also why do you think this means? 1.0 Given that this means two different statements nil.nil IMO, . as a statement separator should be followed by whitespace to eliminate this ambiguity. i.e. nil.nil would be a syntax error, and nil. nil would be acceptable. This opens up the use of . in selectors to do cool things like the old multiple inheritance syntax where one could do directed sends such as super Dictionary.at: key if in a subclass with multiple superclasses and wanting to disambiguate which of multiple superclass implementations one wanted to invoke.
What is the state of RBParser in Squeak about that?
RBParser is not in trunk, it's an add-on. No idea which/where is the latest Squeak-compatible version...
Thierry
2015-09-24 12:03 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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.html
2015-09-24 11:39 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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... There is no such thing in the language.
Oh, and this even has changed in Squeak a few years ago:
-------------------------------------------------------
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 <bera.clement@gmail.com>:
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 < bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be :
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
-- _,,,^..^,,,_ best, Eliot
2015-09-25 21:16 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolas,
On Thu, Sep 24, 2015 at 5:01 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2015-09-24 13:23 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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).
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)?
We should keep #(1 - 2) provided it is interpreted as #(1 #'-' 2). The # tags are noisy (if not ugly) and have never been necessary for literal symbols inside arrays. -2 is quite different from - 2.
Agree, that's one good reason to not accept - 2 as a valid literal, for me it's different than -2. Separators have one semantic: they separrate. white spaces are separators.
Also why do you think this means?
1.0
Given that this means two different statements
nil.nil
IMO, . as a statement separator should be followed by whitespace to eliminate this ambiguity. i.e. nil.nil would be a syntax error, and nil. nil would be acceptable. This opens up the use of . in selectors to do cool things like the old multiple inheritance syntax where one could do directed sends such as super Dictionary.at: key if in a subclass with multiple superclasses and wanting to disambiguate which of multiple superclass implementations one wanted to invoke.
Dan said that he didn't want to make the separator mandatory, but I guess he meant to apply this rule to an expression. Forcing a separator between sentences would not hurt IMO too. In any case, I never saw code written without separators between sentences.
What is the state of RBParser in Squeak about that?
RBParser is not in trunk, it's an add-on. No idea which/where is the latest Squeak-compatible version...
Thierry
2015-09-24 12:03 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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.html
2015-09-24 11:39 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
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... There is no such thing in the language.
Oh, and this even has changed in Squeak a few years ago:
-------------------------------------------------------
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 <bera.clement@gmail.com>:
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 < bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be :
debug it on the first one gives "MNU: receiver of
"doSemanticAnalyisIn:"
is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
-- _,,,^..^,,,_ best, Eliot
On Sat, Sep 26, 2015 at 4:17 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2015-09-25 21:16 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Nicolas,
On Thu, Sep 24, 2015 at 5:01 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2015-09-24 13:23 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:
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).
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)?
We should keep #(1 - 2) provided it is interpreted as #(1 #'-' 2). The # tags are noisy (if not ugly) and have never been necessary for literal symbols inside arrays. -2 is quite different from - 2.
Agree, that's one good reason to not accept - 2 as a valid literal, for me it's different than -2. Separators have one semantic: they separrate. white spaces are separators.
Indeed. With '-2' being the literal, its a consideration of whether whitespace is allowed within a literal. Otherwise '1 - - 1' should evaluate to 2 ?? Currently it errors, which seems correct. '1 - -1' evaluates correctly to 2.
Also why do you think this means?
1.0
Given that this means two different statements
nil.nil
IMO, . as a statement separator should be followed by whitespace to eliminate this ambiguity. i.e. nil.nil would be a syntax error, and nil. nil would be acceptable. This opens up the use of . in selectors to do cool things like the old multiple inheritance syntax where one could do directed sends such as super Dictionary.at: key if in a subclass with multiple superclasses and wanting to disambiguate which of multiple superclass implementations one wanted to invoke.
Dan said that he didn't want to make the separator mandatory, but I guess he meant to apply this rule to an expression. Forcing a separator between sentences would not hurt IMO too. In any case, I never saw code written without separators between sentences.
This sounds reasonable to me. cheers -ben
What is the state of RBParser in Squeak about that?
RBParser is not in trunk, it's an add-on. No idea which/where is the latest Squeak-compatible version...
Thierry
2015-09-24 12:03 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
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.html
2015-09-24 11:39 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
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... There is no such thing in the language.
Oh, and this even has changed in Squeak a few years ago:
-------------------------------------------------------
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 <bera.clement@gmail.com>:
2015-09-24 8:19 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
- 250 * 1.5 returns -2.25
why is this valid syntax?
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.
On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc@openinworld.com> wrote:
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 <bera.clement@gmail.com> 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 phil@highoctane.be <phil@highoctane.be>:
debug it on the first one gives "MNU: receiver of "doSemanticAnalyisIn:" is nil.
Weird.
On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo@free.fr> wrote:
Hi guys
I think that this is quite bad that - 250 * 1.5 returns -2.25
while
-250 * 1.5 return 375
stef
-- _,,,^..^,,,_ best, Eliot
During the lecture I saw that {(10@20) . (30@40)} is printed as {(10@20). (30@40)} and I think that it would much nicer to have {(10@20) . (30@40)}
participants (11)
-
Ben Coman -
Clément Bera -
Eliot Miranda -
Marcus Denker -
Nicolai Hess -
Nicolas Cellier -
Peter Uhnák -
phil＠highoctane.be -
stepharo -
Thierry Goubier -
Tudor Girba