Re: [Pharo-dev] Pharo and special unary selectors

Fri, 17 Nov 2017 15:57:07 -0800

--- Begin Message --- 
Personnally, I against adding those special symbols.  They add close to nothing 
(except complexity in the parser) to what we can actually do!
Besides, what does 30$ + 17$ add up to?  Oh!  Did I tell you it was actually 
$30USD + $17CAN ? :)


----------------- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein) 

    On Friday, November 17, 2017, 6:41:11 PM EST, Ben Coman 
<[email protected]> wrote:  
 
 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 
<[email protected]> wrote:



2017-11-17 18:32 GMT+01:00 Thierry Goubier <[email protected]>:

Le 17/11/2017 à 10:14, Nicolas Cellier a écrit :



2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <[email protected] 
<mailto:[email protected]>>:

    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'% printanObject '% 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 <[email protected]
    <mailto:[email protected]>> 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.

--- End Message ---

Reply via email to