Le 17 nov. 2017 1:03 PM, "Nicolas Cellier" < [email protected]> a écrit :
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. What I meant is that at the tokenifier stage, the parser already combines characters into a single token. So the parser is yes using only a single token lookahead,, but where a token can be multiple characters. > 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... I agree. > 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... I haven't seen this one coming. So we need a new syntax meaning that there is no parameter, like + ][ or anything yet unused... It starts to look very convoluted. Yuck. Thierry > 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 >> >> 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. >> >> >> >> > >
