[Cuis-dev] Parser gets confused when using $| in binary selectors

Fri May 13 08:28:47 PDT 2022

Hi, I was wondering about the same a while ago and googled up the rationale behind the existing implementation might have been to keep Smalltalk an LL(1) language (could it also "really" explain why 3 + 4 * 5 is not 23 but 35?) ; so eventually I implemented @- under Number :)
Best,

--

Jaromír Matas

________________________________
From: Cuis-dev <cuis-dev-bounces at lists.cuis.st> on behalf of Hernan Wilkinson via Cuis-dev <cuis-dev at lists.cuis.st>
Sent: Friday, May 13, 2022 5:02:16 PM
To: Luciano Notarfrancesco <luchiano at gmail.com>
Cc: Hernan Wilkinson <hernan.wilkinson at 10pines.com>; Juan Vuletich <JuanVuletich at zoho.com>; Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st>; Martin McClure <martin at hand2mouse.com>
Subject: Re: [Cuis-dev] Parser gets confused when using $| in binary selectors

I would go back to the original behavior. if 1 @- 2 sends the message @- to 1 then that message will have to be implemented in Number to get the expected behavior, and that will happen with 1 *- 2 and 1 /- 2 and so on.
This is a case where we have to be pragmatic and we have to prioritize how these messages are modeling the arithmetic of numbers.
For me, this is an example where a special case in the syntax makes it more easy to use, closer to the domain problem where those messages are used 99% of the time (mathematic) and that will generate the least number of surprises.
We already have problems explaining why 3 + 4 * 5 is not 23 but 35, I can not imagine myself explaining why 1 at -2 is not the same as 1 at - 2
when -2 and - 2 are the same.
And also, I think we have to give credit to the people that defined this behavior a long (Dan Ingalls & co). For sure they had this same discussion and they decided to go this way for a reason, and the reason for me has to do with what I mentioned earlier.
Going back to the original behavior makes the behavior of these messages more natural and it will maintain compatibility with other Squeak descendant Smalltalks.

On Fri, May 13, 2022 at 11:38 AM Luciano Notarfrancesco <luchiano at gmail.com<mailto:luchiano at gmail.com>> wrote:
Sounds good to me, but not a requirement for my use case, if you think it would complicate the parser you don’t need to do it (at least not for me).

On Fri, 13 May 2022 at 9:31 PM Juan Vuletich <JuanVuletich at zoho.com<mailto:JuanVuletich at zoho.com>> wrote:
I'm pretty sure I can tweak the parser to treat specially $- as last char of a binary selector, so that

1 at -2 creates a Point.
1 @ -2 also creates a Point.
1 @- 2 (note the space between - and 2) sends #@-, whatever that might mean.

I know it wouldn't be strictly ANSI, but that shouldn't be too important.

Do you folks think this would be reasonable behavior?

Thanks,

On 5/13/2022 11:07 AM, Luciano Notarfrancesco via Cuis-dev wrote:
Can you think of other characters that could be problematic when allowing them in binary selectors? I don’t use selectors ending with $-, and I agree that the original behavior is more convenient and intuitive. The only disadvantage of keeping the original behavior for this case would be not being ANSI compliant, not a problem for me.

On Fri, 13 May 2022 at 8:58 PM Luciano Notarfrancesco <luchiano at gmail.com<mailto:luchiano at gmail.com>> wrote:
Personally I don’t mind if we decide to make an exception for the special case of $-, but only for that character, because I want to have more options available for binary operators (for example with $|).

On Fri, 13 May 2022 at 8:53 PM Hernan Wilkinson <hernan.wilkinson at 10pines.com<mailto:hernan.wilkinson at 10pines.com>> wrote:
Even more... this change makes things like: 1*-2 or 1/-2 or 1//-2 or 1+-2, etc etc etc to generate an error.
I think it does not make sense.... any common programmer will expect 1*-2 to return -2 and not an error.
I think we should get back to the previous behavior.

What do you think?

Hernan.

On Fri, May 13, 2022 at 10:34 AM Hernan Wilkinson <hernan.wilkinson at 10pines.com<mailto:hernan.wilkinson at 10pines.com>> wrote:
Hi all!
 I'm just wondering why you guys think that having @- as a unary selector is better than interpreting it as valid for a negative y of a point...
 I mean, it is much more common to write 1 at -1 as a point whose y is -1 than to use @- as a selector...
 Newcomers will have bit time problems to understand why 1 at -1 does not generate a point with a -1 as the y, unless the @- message is implemented in Point to create a point with the negation of the parameter which is for me an unnecessary indirection...
 I mean, what other class is going to implement a message such as @- ?
 It seems to me more useful the behavior we had previous to this change.

Hernan.

On Fri, May 13, 2022 at 9:52 AM Luciano Notarfrancesco via Cuis-dev <cuis-dev at lists.cuis.st<mailto:cuis-dev at lists.cuis.st>> wrote:
If you don't mind, I think these printOns look better (either one)

On Fri, May 13, 2022 at 2:36 AM Luciano Notarfrancesco <luchiano at gmail.com<mailto:luchiano at gmail.com>> wrote:
Oh, great, thanks! I was just thinking that “1@(-1)” could have been a better choice for the fix, and that maybe we should have a preference to avoid overwriting timestamp and other people’s initials when we do trivial changes like this.

On Fri, 13 May 2022 at 3:41 AM Juan Vuletich <JuanVuletich at zoho.com<mailto:JuanVuletich at zoho.com>> wrote:
Thanks Folks!

Luciano, I just pushed your changes. I also found an instance of '\\-' that I fixed too. There are several changes required for optional packages in the Cuis-Smalltalk organization. Will push them tomorrow.

WRT to Decompiler, decompiled code is actually OK, with a space after binary selectors. What was wrong was the #storeString of literal Points. Fixed Point>>#printOn: for that. Now DecompilerTests pass.

Cheers!

On 5/9/2022 3:21 PM, Luciano Notarfrancesco via Cuis-dev wrote:
Martin,
Thanks for the very detailed explanation! I went ahead and replaced '@-' with '@ -' in the image and the tests. There are still 10 tests producing errors because the decompiler decompiles it without the space, tho.

On Mon, May 9, 2022 at 5:04 PM Martin McClure <martin at hand2mouse.com<mailto:martin at hand2mouse.com>> wrote:
The ANSI Smalltalk grammar says that "@-" should be a valid binary selector, and would require whitespace in "1@ -1" to interpret the argument as a literal negative one.

The Blue Book grammar, though, does not allow "@-" as a binary selector. The Blue Book grammar, as printed, also does not allow "," as a binary selector, even though that was clearly used as a binary selector in Smalltalk-80. The Blue Book grammar also does not talk about whitespace at all, even though that is clearly required in some places, so the Blue Book is a bit fuzzier than one would want as a grammar reference.

Going with ANSI-like grammar and putting a space in expressions like "1 @- 1" makes more sense to me. Allows more valid selectors, and the code is more readable with the whitespace.

Regards,
-Martin

On 5/9/22 03:48, Luciano Notarfrancesco via Cuis-dev wrote:
After this change '1 at -1' is parsed as a binary message #@-, and this causes some base image tests to fail. Should we add a space between @ and -1 or should we fix the parser?

On Fri, May 6, 2022 at 1:56 PM Luciano Notarfrancesco <luchiano at gmail.com<mailto:luchiano at gmail.com>> wrote:
That was quick. Thanks a lot!

On Fri, 6 May 2022 at 8:55 PM Juan Vuletich <JuanVuletich at zoho.com<mailto:JuanVuletich at zoho.com>> wrote:
On 5/6/2022 10:48 AM, Luciano Notarfrancesco via Cuis-dev wrote:
I’m not sure I was clear, I meant a method implementing those messages, not sending those messages.

On Fri, 6 May 2022 at 1:22 PM Luciano Notarfrancesco <luchiano at gmail.com<mailto:luchiano at gmail.com>> wrote:
I’m getting “Argument name expected” when trying to compile a method with selector <|. On the other hand, |>, | and || all compile fine as binary selectors, but || breaks syntax highlighting.

Sure. Fixes at GitHub now.

A small detail: Now an empty temporal declaration `||` is parsed as a binary selector, and therefore marked as invalid. Not a big deal. We'd just remove any such.

Cheers,

--
Juan Vuletich
www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

--
Juan Vuletich
www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

--
Cuis-dev mailing list
Cuis-dev at lists.cuis.st<mailto:Cuis-dev at lists.cuis.st>
https://lists.cuis.st/mailman/listinfo/cuis-dev

--
[X]<https://10pines.com/>
Hernán Wilkinson
Software Developer & Coach

Alem 896, Floor 6, Buenos Aires, Argentina

+54 11 6091 3125

@HernanWilkinson

--
[X]<https://10pines.com/>
Hernán Wilkinson
Software Developer & Coach

Alem 896, Floor 6, Buenos Aires, Argentina

+54 11 6091 3125

@HernanWilkinson

--
Juan Vuletich
www.cuis-smalltalk.org<http://www.cuis-smalltalk.org>
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
https://independent.academia.edu/JuanVuletich
https://www.researchgate.net/profile/Juan-Vuletich
https://patents.justia.com/inventor/juan-manuel-vuletich
https://twitter.com/JuanVuletich

--
[https://10pines.github.io/email-signature/10pines-firma@2x.png]<https://10pines.com/>
Hernán Wilkinson
Software Developer & Coach

Alem 896, Floor 6, Buenos Aires, Argentina

+54 11 6091 3125

@HernanWilkinson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220513/a3dbc69b/attachment-0001.htm>