[Pharo-dev] Pharo and special unary selectors

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Nov 17 15:02:38 EST 2017


2017-11-17 18:32 GMT+01:00 Thierry Goubier <thierry.goubier at gmail.com>:

> Le 17/11/2017 à 10:14, Nicolas Cellier a écrit :
>
>>
>>
>> 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli at gmail.com <mailto:
>> g.cotelli at gmail.com>>:
>>
>>     I would really like to see % removed as a binary selector and
>>     available to use in unary or keyword ones. The only implementor in a
>>     Pharo 6 image is:
>>
>>       % aNumber
>>
>>          ^ self \\ aNumber
>>
>>
>> +1, such alias has nothing to do in Kernel
>>
>>     So it's juts aliasing \\ , and % most widespread usage in the real
>>     world is por percentages (the use in modular arithmetic is more a
>>     programming thing that math notation I think).
>>
>>     And for allowing more Unicode code points for selector names I'm
>>     totally in for Symbols, Arrows, Math Symbols, etc... We just need to
>>     analyse the ones that makes sense as binary selectors, and the ones
>>     allowed for unary and keyword ones. This will allow us to write
>>     pretty cool DSLs.
>>
>>     Just my opinion.
>>
>> This could also be the case for punctuation like ! and ?
>>
>> The idea of Torsten is more generic, any combination of binary char could
>> be used.
>>  From what I understand from https://en.wikipedia.org/wiki/LR_parser we
>> would just have to scan one more token ahead for deciding if unary or
>> binary, and could preserve our simple shift reduce steps...
>>
>
> The Smalltalk parsers being handwritten, there wouldn't be shift/reduces
> to contend with, and, anyway, the lexer doesn't shift/reduce; it would
> simply creates a token up to the next separator (that is goble up the next
> space/cr/end of line dot/closing parenthesis/etc...)
>

I don't have academical cursus, so I may be approximate, but the manually
written parsers just have to read a single token ahead so far, and linearly
build the parseNode, to me it was equivalent.


> So it seems doable for resolving the send.
>>
>
> Sort of. The parser difficulty would be this one:
>
> anObject % print
>

Yes, that's a severe limitation. Context free => it's a binary... Or we
have to use ( ).
But then it's unfriendly to have different rules for unary symbols versus
unary words...
It devaluates the idea...


> Is this a binary selector with a print argument or two unary selectors?
>
> Using the symbol table when you parse would solve it, but that is
> certainly not context free...
>
> More problematic would be the declaration of method, if we have both a
>> unary + and a binary +, we will need new syntax for marking the difference.
>>
>
> In most cases, distinguishing between unary + declaration and binary +
> declaration would be doable:
>
> + whatever
>
> is the start of a binary selector
>
> + ^ self
>
> is the start (or the declaration of) an unary selector.
>
> But writing
>
> + self
>
> Can be interpreted as either unary plus doing self, or binary + method
> definition...
>

Yes I was thinking of similar issues...

+ b | c |

a binary plus with unused temp and implicit ^self, or unary + with binary |
sent to b with unary (c |) parameter etc...
So we need a new syntax meaning that there is no parameter, like + ][ or
anything yet unused...



> Whether it's worth or not is another matter...
>>
>
> Well, one should probably try to implement the various parsers for that
> (extend RB, extend the SmaCC Smalltalk parser, extend the Petit Parser) to
> see how much complexity it would bring.
>
> Coming up with strange interpretations one could do with that syntax can
> be helpfull as well.
>
> Regards,
>
> Thierry
>
>     On Fri, Nov 17, 2017 at 6:32 AM, Torsten Bergmann <astares at gmx.de
>>     <mailto:astares at gmx.de>> wrote:
>>
>>         Hi,
>>
>>         just something to think about: one thing I always liked about
>>         Smalltalk is that it allows for nice DSL's. We have nice things
>>         like a unit framework in Pharo, ...
>>
>>         In the most simple case one can easily implement own units just
>>         by providing a unary messages:
>>
>>           1 m
>>           1 second
>>           1 px
>>           1 EUR
>>
>>         One can easily implement an own Money class with a currency and
>>         then do polymorphic tricks like
>>
>>            10 EUR + 20 EUR
>>
>>         But we can currently can not implement special unary selectors
>>         (including special unary selectors with unicode) like:
>>
>>            100 %
>>            20 $
>>            40 €
>>            12 ‰  (for promille)
>>
>>         Especially things like 20 % would be nice for layout issues or
>>         other (Bloc comes to mind).
>>
>>         Maybe we should put that on the roadmap of Pharo because IMHO it
>>         would be cool to support such things in the
>>         future. Dont know how much effort it currently means on the
>>         technical level but maybe others can comment.
>>
>>         Thx
>>         T.
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171117/74c10324/attachment-0002.html>


More information about the Pharo-dev mailing list