[Pharo-dev] Pharo and special unary selectors

Ben Coman btc at openinworld.com
Fri Nov 17 18:40:03 EST 2017


If a valid Smalltalk method identifier contains only... [a-zA-Z][a-zA-Z0-9]*
http://www.osdata.com/programming/firstprograms/valididentifiers.html

then one option could be that unary symbols must touch the previous
identifier, i.e. no intervening whitespace,

  100%
  20$
  40€
  12‰
  portion%
  someMoney$


or pick a new "unary separator/binder"

  100'%    or  100 '%
  20'$       or  20 '$
  40'€       or  40 '€
  12'‰     or  12 '‰
  portion'%
  someMoney'$


or re-use the existing colon which indicates an argument to the right,
to indicate an argument to the left....

  100 :%
  20 :$
  40 :€
  12 :‰  (for promille)
  portion :%
  someMoney :$

which is unambiguous regarding block variable definitions since no messages
are valid in the block variable definition area,
but this may complicate precedence semantics due to its similarity to a
keyword selector,
and would complicate things if the space was missing.



On 18 November 2017 at 04:02, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
> 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?
>>
>
Less ambiguous...
anObject'% print
anObject '% print



>
>> 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...
>
>
a "unary binder" could distinguish them...

binary method definition...
+ self

unary method definition...
'+ self



>  issues...
>
> + b | c |
>
> a binary plus with unused temp and implicit ^self, or unary + with binary
> | sent to b with unary (c |) parameter etc...
>

+ b | c |
binary plus, unused temporary c

'+ b | c |
unary plus, first | is binary, second | is unary
or maybe it would need to be...   '+ b | c'|



> So we need a new syntax meaning that there is no parameter, like + ][ or
> anything yet unused...
>

without '

+ || b | c |
empty local variable definition,  next | is binary, second | is unary

also with local variable...
+ | lv1 | b | c |
+ | lv1 | b | c'|



>
>
>
>> 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
>>>
>>
btw, did the recently announced QA Release Tests add enforcement all
selectors to start with a lowercase?
I felt that one a bit overly-restrictive, which would break such a currency
DSL.

cheers -ben



>>>         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/20171118/72dfe817/attachment-0002.html>


More information about the Pharo-dev mailing list