[Cuis-dev] Parser gets confused when using $| in binary selectors
Andres Valloud
ten at smallinteger.com
Fri May 13 07:43:16 PDT 2022
Perhaps this shows the syntax as defined is ambiguous. Consider also
binary selectors such as #=-. Does x=-3 mean x = -3, or does it mean x
=- 3? For this reason, and for the sake of consistency, I think there
should be a separating character between the selector, the receiver, and
the arguments. This also emphasizes the language is built around
sending messages, rather than invoking special operators and keywords.
Suppose you treat the character $- as a special case because it can be
part of a literal. What happens when later some other character needs
to be a part of a selector even though it can also be part of a literal?
And can you add new literals when doing so makes previously (barely)
unambiguous code ambiguous?
Consider code like this: 'abc' + $d. Does it mean that #+$ is forbidden
forever as a selector? How about #+#, in the case of #(1 2 3) + #(4)
written without spaces?
To me, this all seems to come from the ambiguity caused by the apparent
economy of omitting a space character. Some might argue that spaces
waste time because now you have to type more. Recall programmers spent
about 90% of the time reading code, rather than writing it. So, this
alleged economy is optimizing the uncommon case --- or perhaps it
targets code that is written once, read never.
On 5/13/22 7:30 AM, Juan Vuletich via Cuis-dev 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/Cuis-Smalltalk/Cuis-Smalltalk-Dev>
>>>> https://github.com/jvuletich <https://github.com/jvuletich>
>>>> https://www.linkedin.com/in/juan-vuletich-75611b3 <https://www.linkedin.com/in/juan-vuletich-75611b3>
>>>> https://independent.academia.edu/JuanVuletich <https://independent.academia.edu/JuanVuletich>
>>>> https://www.researchgate.net/profile/Juan-Vuletich <https://www.researchgate.net/profile/Juan-Vuletich>
>>>> https://patents.justia.com/inventor/juan-manuel-vuletich <https://patents.justia.com/inventor/juan-manuel-vuletich>
>>>> https://twitter.com/JuanVuletich <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/Cuis-Smalltalk/Cuis-Smalltalk-Dev>
>> https://github.com/jvuletich <https://github.com/jvuletich>
>> https://www.linkedin.com/in/juan-vuletich-75611b3 <https://www.linkedin.com/in/juan-vuletich-75611b3>
>> https://independent.academia.edu/JuanVuletich <https://independent.academia.edu/JuanVuletich>
>> https://www.researchgate.net/profile/Juan-Vuletich <https://www.researchgate.net/profile/Juan-Vuletich>
>> https://patents.justia.com/inventor/juan-manuel-vuletich <https://patents.justia.com/inventor/juan-manuel-vuletich>
>> https://twitter.com/JuanVuletich <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
>> <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 Vuletich
> 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
>
>
More information about the Cuis-dev
mailing list