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'% 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 <[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. >>> >>
