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

Fri May 13 08:39:05 PDT 2022

wow, I did not know about those changes in Squeak and Pharo...
Anyway, for me the least surprising behavior is the original one, it is
what most of the people will expect to happen.
I understand the consistency of the proposed behavior, but as I said
before, it is an edge case that deserves special treatment.

Cheers!
Hernan.

On Fri, May 13, 2022 at 12:32 PM Martin McClure <martin at hand2mouse.com>
wrote:

> Going back to the original behavior makes the behavior of these messages
> more natural and it will maintain compatibility with other Squeak
> descendant Smalltalks.
>
>
> If compatibility is desirable, the ANSI spec is often (but not always) a
> good guide.
>
> As far as Squeak-descendant Smalltalks, for "1 at -2" Squeak puts up a
> warning about "ambiguous selector" and asks you to choose which
> interpretation to use. Pharo interprets "1 at -2" as a send of #'@-'. So
> this change would seem to make Cuis *more* compatible than the original
> behavior.
>
> And it gets rid of the special-casing of $- in binary selectors, which
> increases the simplicity and regularity of the language, some of the
> characteristics that are so great about Smalltalk.
>
> Regards,
> -Martin
>
> On 5/13/22 08:02, Hernan Wilkinson via Cuis-dev wrote:
>
> 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> 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>
>> 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> 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> 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> 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> 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> 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>
>>> 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>
>>> 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> wrote:
>>>
>>> That was quick. Thanks a lot!
>>>
>>> On Fri, 6 May 2022 at 8:55 PM Juan Vuletich <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>
>>> 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 Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3https://independent.academia.edu/JuanVuletichhttps://www.researchgate.net/profile/Juan-Vuletichhttps://patents.justia.com/inventor/juan-manuel-vuletichhttps://twitter.com/JuanVuletich
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3https://independent.academia.edu/JuanVuletichhttps://www.researchgate.net/profile/Juan-Vuletichhttps://patents.justia.com/inventor/juan-manuel-vuletichhttps://twitter.com/JuanVuletich
>>>
>>> --
>>> Cuis-dev mailing list
>>> Cuis-dev at lists.cuis.st
>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>
>>>
>>>
>>> --
>>> <https://10pines.com/> Hernán Wilkinson Software Developer & Coach
>>>
>>> Alem 896, Floor 6, Buenos Aires, Argentina
>>>
>>> +54 11 6091 3125
>>>
>>> @HernanWilkinson
>>>
>>>
>>>
>>> --
>>> <https://10pines.com/> Hernán Wilkinson Software Developer & Coach
>>>
>>> Alem 896, Floor 6, Buenos Aires, Argentina
>>>
>>> +54 11 6091 3125
>>>
>>> @HernanWilkinson
>>>
>>>
>>>
>>> --
>>> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3https://independent.academia.edu/JuanVuletichhttps://www.researchgate.net/profile/Juan-Vuletichhttps://patents.justia.com/inventor/juan-manuel-vuletichhttps://twitter.com/JuanVuletich
>>>
>>>
>
> --
> <https://10pines.com/> Hernán Wilkinson Software Developer & Coach
>
> Alem 896, Floor 6, Buenos Aires, Argentina
>
> +54 11 6091 3125
>
> @HernanWilkinson
>
>
>

-- 
<https://10pines.com/>Hernán WilkinsonSoftware 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/95a1d2e8/attachment-0001.htm>