November 2017 - Pharo-dev - lists.pharo.org

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

by Benoit St-Jean

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 <btc(a)openinworld.com> wrote: If a valid Smalltalk method identifier contains only... [a-zA-Z][a-zA-Z0-9]*http://www.osdata.com/programming/firstprograms/validide… 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(a)gmail.com> wrote: 2017-11-17 18:32 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: Le 17/11/2017 Ã 10:14, Nicolas Cellier a Ã©critÂ : 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@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'% 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 <astares(a)gmx.de Â Â <mailto:astares@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.

Nov. 17, 2017

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

by Thierry Goubier

Le 17 nov. 2017 1:03 PM, "Nicolas Cellier" < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : 2017-11-17 18:32 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 17/11/2017 Ã 10:14, Nicolas Cellier a Ã©crit : > >> >> >> 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com <mailto: >> g.cotelli(a)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. 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 <astares(a)gmx.de >> <mailto:astares@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 >> >> 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. >> >> >> >> > >

Nov. 17, 2017

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

by Ben Coman

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(a)gmail.com> wrote: > > > 2017-11-17 18:32 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Le 17/11/2017 Ã 10:14, Nicolas Cellier a Ã©crit : >> >>> >>> >>> 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com <mailto: >>> g.cotelli(a)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(a)gmx.de >>> <mailto:astares@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. >>> >>

Nov. 17, 2017

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

by Thierry Goubier

Le 17/11/2017 Ã 11:08, Sven Van Caekenberghe a Ã©critÂ : > Parsing difficulty also means that it is harder for humans to understand, to explain to (new) users. Agreed. This is a significant issue in some programming languages. > It would be pretty strange to have binary selectors that are unary, is my first reaction. Or that it could be both... An unary +, then a binary +, maybe not in the same class... Thierry > >> On 17 Nov 2017, at 18:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Le 17/11/2017 Ã 10:14, Nicolas Cellier a Ã©crit : >>> 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@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...) >> >>> So it seems doable for resolving the send. >> >> Sort of. The parser difficulty would be this one: >> >> anObject % print >> >> 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... >> >>> 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(a)gmx.de >>> <mailto:astares@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 >>> 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. >> >> > > >

Nov. 17, 2017

Re: [Pharo-dev] [ci-announces] CI capacity problems, help wanted !

by Stephane Ducasse

Hi Bruno We will have a look. Now the failures/erasure of the configurations this summer did not really help us. We still not fully recovered. Once Pharo will be managed on git. I think that many of our community jobs will be migrated to travis and other services. Stef On Thu, Nov 16, 2017 at 1:02 PM, Bruno Carrez <bruno.carrez(a)inria.fr> wrote: > Dear CI users, > > As some of you may have noticed, the CI service is in capacity troubles. > Most VM deployment fail due to a lack of resources. > > A lot of VMs use a high-end hardware configuration (XL or XXL), but you must > be aware that cloudstack is a mutalised service; so, it is important to use > the right configuration for your real needs. > It is not acceptable to have unused or oversized slaves on one side, and > stucked users on the other side that cannot use the service. > > A lot of users are affected by this issue and are unable use the platform at > all ! > > So I highly recommend to check if you can reduce your footprint on the > service: > > - by downgrading your oversized slaves, > - or deleting your unused slaves > > If you donât know how to decrease the slave configuration, issue a support > ticket and we will be glad to help you. > > Thanks in advance, in the name of all the ci users. > > - The CI team >

Nov. 17, 2017

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

by Nicolas Cellier

2017-11-17 18:32 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Le 17/11/2017 Ã 10:14, Nicolas Cellier a Ã©crit : > >> >> >> 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com <mailto: >> g.cotelli(a)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? > > 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... So we need a new syntax meaning that there is no parameter, like + ][ or anything yet unused... > 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(a)gmx.de >> <mailto:astares@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 >> >> 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. >> >> >> >> > >

Nov. 17, 2017

Re: [Pharo-dev] Little Chapter on Hash methods

by Stephane Ducasse

tx ALOT On Fri, Nov 17, 2017 at 7:04 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote >> In the tips and tricks booklet, I added a simple chapter on hash. > > Cool! I committed a native english grammar review pass :) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Nov. 17, 2017

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

by Sven Van Caekenberghe

Parsing difficulty also means that it is harder for humans to understand, to explain to (new) users. It would be pretty strange to have binary selectors that are unary, is my first reaction. > On 17 Nov 2017, at 18:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 17/11/2017 Ã 10:14, Nicolas Cellier a Ã©crit : >> 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@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...) > >> So it seems doable for resolving the send. > > Sort of. The parser difficulty would be this one: > > anObject % print > > 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... > >> 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(a)gmx.de >> <mailto:astares@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 >> 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. > >

Nov. 17, 2017

Re: [Pharo-dev] Little Chapter on Hash methods

by Sean P. DeNigris

Stephane Ducasse-3 wrote > In the tips and tricks booklet, I added a simple chapter on hash. Cool! I committed a native english grammar review pass :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 17, 2017

[Pharo 7.0-dev] Build #305: 20709-do-not-create-pharo-core-symlink-during-the-image-building

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #305 was: SUCCESS. The Pull Request #492 was integrated: "20709-do-not-create-pharo-core-symlink-during-the-image-building" Pull request url: https://github.com/pharo-project/pharo/pull/492 Issue Url: https://pharo.fogbugz.com/f/cases/20709 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 17, 2017