I just randomly ran into this project https://github.com/ba-st/aconcagua which seems to be designed around such unary selectors.
On Sat, Nov 18, 2017 at 12:55 AM, Benoit St-Jean via Pharo-dev < pharo-dev@lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstj...@yahoo.com> > To: Pharo Development List <pharo-dev@lists.pharo.org> > Cc: > Bcc: > Date: Fri, 17 Nov 2017 23:55:56 +0000 (UTC) > Subject: Re: [Pharo-dev] Pharo and special unary selectors > 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 < > b...@openinworld.com> 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 <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > 2017-11-17 18:32 GMT+01:00 Thierry Goubier <thierry.goub...@gmail.com>: > > Le 17/11/2017 à 10:14, Nicolas Cellier a écrit : > > > > 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cote...@gmail.com <mailto: > g.cote...@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 > <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 <asta...@gmx.de > <mailto:asta...@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. > > > >
