On 08 Nov 2014, at 5:55 , Werner Kassens <wkassens@libello.com> wrote:

but if you omit the space between - and 3 the old compiler understands it too, hence its just a convenience thing that cant lead to misunderstandings, or? btw opal also understands this: - 3@2. --> (-3@2) i mean, its obvious nevertheless that "-" is not a method like negated, but part of a number and opal is just a bit more flexible with number formatting. werner

On 11/08/2014 04:40 PM, Nicolai Hess wrote:

...

Old compiler refuses to accept this code:

- 4 @ -5 ^-- nothing more expected

Opal compiler does just fine:

- 4 @ -5 -> (-4@ -5)

who is right?

IMHO, the old compiler is right, whitespace should not be allowed in literals. For instance, 3 @ - 5 reads like gibberish. Cheers, Henry

On 10 Nov 2014, at 8:45 , Thierry Goubier <thierry.goubier@gmail.com> wrote:

2014-11-10 7:59 GMT+01:00 Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>>:

IMHO, the old compiler is right, whitespace should not be allowed in literals.

Whitespace can be \t or \n,\r which makes for strange literals (multilines) such as:

-

5

And would create ambiguity in some cases

is 4 - 5 two literals, or is it two literals separated by the - operator ?

For instance, 3 @ - 5 reads like gibberish.

But is 3 @ -5 a problem or not ? Why is the old compiler accepting -3 @ 5, and not 3 @ -5 ?

3 @ -5 is not a problem, and accepted by both. 3 @ - <space> 5 is what I object to (and Opal allows) 3 @-5 and/or 3 @- 5 is (rightly) disallowed by both. Cheers, Henry

I have tried this on my latest Dolphin (Pro 6.1 Beta 2): 3 @ -5 is accepted and interpreted correctly. 3 @ - 5 is rejected with message: 'Error - incorrect expression start'; the caret is pointing at the - sign. So the Opal behaviour does not mirror that of Dolphin. Hope this helps Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Thierry Goubier 2014-11-10 8:47 GMT+01:00 Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no> >: 3 @ -5 is not a problem, and accepted by both. 3 @ - <space> 5 is what I object to (and Opal allows) RBParser allows this one even if old Compiler dissallows it (i.e. in Pharo 2). I haven't tracked if Opal follows the RBParser on that or if this is the reverse (Opal pushed changes on RBParser). I suspect all things RB in Pharo (and Squeak?) are a port from the Dolphin version of RB, which means this is allowed in quite a few other smalltalks (Dolphin?, VW?). I haven't checked if the SmaCC Smalltalk parser accept that. Note: 4 - 5 in RBParser does what you would expect. 4 - - 5 as well. 3 @-5 and/or 3 @- 5 is (rightly) disallowed by both. That one is easier and expected. My position would be twofold: - RBParser is, IMHO, a good parser and I would follow its interpretation. That Opal reuses it is a good point for me. - As a programming language designer (and parser implementor), accepting - 5 is user friendly, but a bit too contextual in the lexer to be nice to implement. Thierry Cheers, Henry

I believe that x - - y would give you an error. 4 - - 5 in parsing is a different beast, because you consider - 5 as a single token. Thierry 2014-11-10 12:36 GMT+01:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:

In VisualWorks: 3 @ *Argument expected ->*- 5

I guess what one expects is a matter of habit, personally I'd expect x - - y to yield a parsing error.

Cheers, Henry

On 10 Nov 2014, at 12:06 , PBKResearch <peter@pbkresearch.co.uk> wrote:

I have tried this on my latest Dolphin (Pro 6.1 Beta 2): 3 @ -5 is accepted and interpreted correctly. 3 @ - 5 is rejected with message: 'Error - incorrect expression start'; the caret is pointing at the - sign. So the Opal behaviour does not mirror that of Dolphin.

Hope this helps

Peter Kenny

*From:* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org <pharo-users-bounces@lists.pharo.org>] *On Behalf Of *Thierry Goubier

2014-11-10 8:47 GMT+01:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:

3 @ -5 is not a problem, and accepted by both. 3 @ - <space> 5 is what I object to (and Opal allows)

RBParser allows this one even if old Compiler dissallows it (i.e. in Pharo 2).

I haven't tracked if Opal follows the RBParser on that or if this is the reverse (Opal pushed changes on RBParser). I suspect all things RB in Pharo (and Squeak?) are a port from the Dolphin version of RB, which means this is allowed in quite a few other smalltalks (Dolphin?, VW?).

I haven't checked if the SmaCC Smalltalk parser accept that. Note: 4 - 5 in RBParser does what you would expect. 4 - - 5 as well.

3 @-5 and/or 3 @- 5 is (rightly) disallowed by both.

That one is easier and expected. My position would be twofold: - RBParser is, IMHO, a good parser and I would follow its interpretation. That Opal reuses it is a good point for me. - As a programming language designer (and parser implementor), accepting - 5 is user friendly, but a bit too contextual in the lexer to be nice to implement.

Thierry

Cheers, Henry

Let me restate what i meant: if you enter 5--4 in squeak for example, the parser asks you whether you meant 5 - -4 or 5 -- 4. werner On 11/10/2014 03:28 PM, Werner Kassens wrote:

Of course. i was talking about x -- y not x - - y. werner

On 11/10/2014 03:17 PM, Thierry Goubier wrote:

...

I believe that x - - y would give you an error.

4 - - 5 in parsing is a different beast, because you consider - 5 as a single token.

dont know but <g> let me try yet another attempt at rephrasing this. suppose you ask an intermediate beginner how 5--4 would be parsed, as: a) 5 - -4 b) 5 -- 4 perhaps he does not need to look up the chapter in the pharobook and will choose b). but if he looks into the pharobook he will read under "Binary messages": "Note that −− is not allowed for parsing reasons" (i just checked the latest version) now honestly, dont you think that a) is a serious contender? that is all i wanted to say. werner

On 11/12/2014 11:29 AM, José Comesaña wrote:

Well, I don't understand why the book says that because in fact you can define a -- binary method: yes, that is what i said, it's just an irritating bug in the book. werner

2014-11-10 12:47 GMT+01:00 Werner Kassens <wkassens@libello.com>:

...

3 @ - <space> 5 is what I object to (and Opal allows) with this i have no problems, it follows simple obvious rules as long as one knows that #@ cant be an unary operator. is 4 - 5 two literals, or is it two literals separated by the - operator ? but then there is no situation in which the - operator can really operate and where a sequence of literals is at the same time possible. ok there is #(4 - 5), but in this case the operator cant operate and first the #()-thing is parsed and then its elements. what has not been mentioned is: 4 -- 5, which in a certain way was (?) problematic: my (old) pharobook (p.64) says: "Note that −− is not allowed for parsing reasons". in this case it should be seen as 4 - -5 and one needed to keep this special case in his mind, but i had no problems defining a #--, which simplifies everything: if there is no special case, then -- has to be parsed as one binary operator. and i only have an old pharobook, a newer one perhaps (?) doesnt state this.

all this just from my simple user perspective of course, but i guess the question was not posed without reason in Pharo-Users. and this simple user prefers freedom over paternalism anyday. werner

Thanks for all the answers, so, for better portability, maybe we should dissallow opals current behavior and only accept "-5" and not "- 5" as negative numbers? Nicolai

2014-11-22 13:23 GMT+01:00 Werner Kassens <wkassens@libello.com>:

...

Thanks for all the answers, so, for better portability, maybe we should dissallow opals current behavior and only accept "-5" and not "- 5" as negative numbers?

Hi Nicolai, perhaps. if you mean portability pharo->otherLanguage certainly. if you mean otherLanguage->pharo, well you are the specialist, i only know pharo and squeak as smalltalk dialects. of course you know that there exist non-OO-languages that return the same result as opal if you enter "1 + - 2 -->-1". and of course i know that if i want to translate something from those other languages, deleting a <space> is the most simple of my problems.

portability pharo -> other smalltalk languages. Consider you have a library that could be used on other smalltalk systems. And it just don't work because there is a space between the number and the sign.

changing the pov slightly, when do you have to enter a negative number in a program by hand? essentially only if you use that number as a constant (apart from tests of course). numbers are entered often automatically from outside files. ok, then you have those parsers that read in a string in a more flexible way. but wouldnt it make sense if the compiler reacts somewhat similar to those parsers? i for example do have a program, where the user, admittedly not a usual user but essentially me, enters simple inequalities (and here negative numbers are very common) as strings and the compiler eats those strings more or less directly without any additional parser put in between.

i realize that with your reply you'd prefer a fact based argumentation and i readily admit that as a simple user, i see it simple stupid emotionally. if i understand pharo's history correctly, it came into existence because some language developers wanted more freedom. of course syntax controls thinking. i dont have any real problems if you disallow - 5, i use -5 anyway, if it makes sense do it, you are the specialist. but what comes next? will everything you enter into nautilus automatically be pretty-printed? i understand that pharo has grown up now, and it makes complete sense to me that it wants to play with the big boys. perhaps you need a clear-cut simple structured syntax to get accepted by the business community, but not every businessman is a complete idiot and for example mathematica, which understands "1 + - 2", _is_ occasionally used to make some real money. i'd think about how far i'd wanna go with this thought control thing. so much <friendly grin> for my personal pov. werner

thank you werner, for your point of view. If someone came up with a good reason why opals behavior is actually wrong, I would change it. But I think now, it is not that important. We have much more things with higher priority. nicolai