- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by Tim Mackinnon

+1 for #shouldXxx I recall I use it a lot too, and #isXxx where that reads better but am struggling for examples. Tim Sent from my iPhone > On 13 Sep 2019, at 02:37, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > >> On Wed, Sep 11, 2019 at 4:10 AM ducasse <stepharo(a)netcourrier.com> wrote: >> >> >> > On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net> wrote: >> > >> > Would use of ? and ! in unary/keyword selectors be convention or somehow required? If simply convention, then we should start with renaming testing methods to be named is* or has*. >> > flag1 := anInteger even. ânot good" >> > flag2 := anInteger isEven. âbetter" >> > flag3 := anInteger even?. âhow much better?â >> > flag4 := #(1 2 3) includes?: 2. âhow much better?â >> >> I think that I would use ? mainly for unary message >> >> Now Iâm sure that if you look carefully some people use >> >> include >> for the action >> includes >> for the tests >> >> I took include as an example and this is super not intention revealing. >> >> >> lineUpBlockBrackets >> >> lineUpBlockBrackets? >> Now I will rewrite them all as shouldLineUpBlockBrackets or isLineUpBlockBrackets and to me for unary message ? makes it a lot better. >> > > Hi Stef, > > I have been facing this ambiguity a lot too. And my workaround, most of the times, was also to prefer the "question" method with #should. #is just doesn't sound right in my cases, but #should does sound good in most of them. I would still like to find a better one, but for the moment, in my recent years, I am stuck with #should. > > -- > Mariano Martinez Peck > Email: marianopeck(a)gmail.com > Twitter: @MartinezPeck > LinkedIn: www.linkedin.com/in/mariano-martinez-peck > Blog: https://marianopeck.wordpress.com/

Sept. 13, 2019

[Pharo 8.0] Build #732: 4574-confusing-comment-in-ThreadSafeTranscriptendEntry

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

There is a new Pharo build available! The status of the build #732 was: FAILURE. The Pull Request #4581 was integrated: "4574-confusing-comment-in-ThreadSafeTranscriptendEntry" Pull request url: https://github.com/pharo-project/pharo/pull/4581 Issue Url: https://github.com/pharo-project/pharo/issues/4574 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 13, 2019

Re: [Pharo-dev] Allow selected special characters as part of unary and keyword selectors?

by Mariano Martinez Peck

On Wed, Sep 11, 2019 at 4:10 AM ducasse <stepharo(a)netcourrier.com> wrote: > > > > On 11 Sep 2019, at 04:07, James Foster <Smalltalk(a)JGFoster.net> wrote: > > > > Would use of ? and ! in unary/keyword selectors be convention or somehow > required? If simply convention, then we should start with renaming testing > methods to be named is* or has*. > > flag1 := anInteger even. ânot good" > > flag2 := anInteger isEven. âbetter" > > flag3 := anInteger even?. âhow much better?â > > flag4 := #(1 2 3) includes?: 2. âhow much better?â > > I think that I would use ? mainly for unary message > > Now Iâm sure that if you look carefully some people use > > include > for the action > includes > for the tests > > I took include as an example and this is super not intention revealing. > > >> lineUpBlockBrackets > > lineUpBlockBrackets? > Now I will rewrite them all as shouldLineUpBlockBrackets or > isLineUpBlockBrackets and to me for unary message ? makes it a lot better. > > Hi Stef, I have been facing this ambiguity a lot too. And my workaround, most of the times, was also to prefer the "question" method with #should. #is just doesn't sound right in my cases, but #should does sound good in most of them. I would still like to find a better one, but for the moment, in my recent years, I am stuck with #should. -- Mariano Martinez Peck Email: marianopeck(a)gmail.com Twitter: @MartinezPeck LinkedIn: www.linkedin.com/in/mariano-martinez-peck <https://www.linkedin.com/in/mariano-mart%C3%ADnez-peck/> Blog: https://marianopeck.wordpress.com/

Sept. 13, 2019

Re: [Pharo-dev] I have a dream... or why I think that compatibility is an illusion and bring us to the past

by Nicolas Cellier

Funnily, in same period you could find defenders of ? in binary selectors: http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/008893.ht… and more geenral discussion about binary selectors: http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/001466.ht… Stef, u gonna hate me for living in the past ;) But you don't have to be stuck of course :) Le jeu. 12 sept. 2019 Ã 21:39, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > And to finish with ^, hare is an older implementation > > http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/015491.ht… > > And the classical refutation (we should not bother too much about it) > > http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/005777.ht… > > Le jeu. 12 sept. 2019 Ã 20:37, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > >> Note that I also cared to handle ^ as binary selector for Opal >> Unfortunately the issue staled (for good or bad reasons, don't know...) >> >> >> https://pharo.fogbugz.com/f/cases/13078/Allow-upArrow-caret-as-a-binary-sel… >> >> Le mer. 11 sept. 2019 Ã 21:21, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : >> >>> It was just an answer to: >>> >>> > Do not tell me that there is a value in these selectors? >>> >>> I used the same argument for huge?:or!:???and: >>> But I don't think it's a valid argument: it's making induction starting >>> with a restricted set of examples... >>> >>> I also tried to answer to why and when a binary selector would be a >>> "good" selector (elected for core libraries). >>> (since you gave a list of selectors which were OK) >>> >>> I said that I don't really need ? nor ! in binary selectors, but neither >>> do I in unary/keyword selectors >>> (though I also thought using ? for boolean answer, I don't think it's >>> really useful) >>> >>> >>> >>> Le mer. 11 sept. 2019 Ã 20:10, ducasse <stepharo(a)netcourrier.com> a >>> Ã©crit : >>> >>>> Wait I do not understand what you are saying :) >>>> I never said that I want to forbid anything. I just say that I would >>>> like that ? is not consider as a part of a binary selector. >>>> Amâi clearer? >>>> >>>> Stef >>>> >>>> >>>> On 11 Sep 2019, at 19:48, Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>> Ah, and I forgot about your argumentation Stef: >>>> >>>> you cannot forbid binary selectors altogether because some are ugly >>>> @@*+!!! (I think I read this one in Asterix le gaulois) >>>> for the same reasons that >>>> youCanNOtfOrBIDunaYSElectORSWIthletTersBECauSESoMeaREUgly >>>> >>>> Le mer. 11 sept. 2019 Ã 19:44, Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : >>>> >>>>> >>>>> >>>>> Le mer. 11 sept. 2019 Ã 10:40, Serge Stinckwich < >>>>> serge.stinckwich(a)gmail.com> a Ã©crit : >>>>> >>>>>> >>>>>> >>>>>> On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <g.cotelli(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Looks like Christmas season opened early this year :) >>>>>>> >>>>>>> Jokes aside, I'm in favor of changing some of the characters we use >>>>>>> for binary selectors to allow it to be used in keyword/unary messages. >>>>>>> >>>>>>> I'll include % in that list. For me its more useful as a way to >>>>>>> create percentages ( 5 % ) than to be used as a binary message for keeping >>>>>>> an ugly name from C-like languages. >>>>>>> >>>>>>> - Â· is middle dot and it's used in some math operations AFAIR >>>>>>> - Ã is used in math also (it's used as the multiplication sign >>>>>>> for scalars, cross product for vectors and cartesian product for sets) >>>>>>> >>>>>>> One thing that would be really cool is that we can use the full >>>>>>> power of Unicode in methods/class names. Projects like polymath and DSLs >>>>>>> can clearly take advantage of that. Some examples I've just invented, but >>>>>>> can be supported: >>>>>>> >>>>>>> >>>>>>> - â from: 1 to: 5 do: [:i | i + i squared ] >>>>>>> - 1 â¥ 3 >>>>>>> - â anyIn: #( 1 2 4) such: [:x | x isPrime ] >>>>>>> - â includes: 1 >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes I would like to have something like that for PolyMath :-) >>>>>> Is it possible to use Unicode characters for identifiers already ? >>>>>> >>>>>> I working on the port of : https://github.com/len/Domains >>>>>> to Pharo. The author modify the Cuis parser, so he can do things like >>>>>> that : >>>>>> >>>>>> "â is used for direct sums, â for tensor products, Ã for cartesian >>>>>> product, direct product of groups, ring products, and in general for >>>>>> categorical products." >>>>>> >>>>> >>>>> Of course we want to be able to use those selectors: â â etc... >>>>> Not using those selectors in core image is one thing, forbiding their >>>>> usage for every package is another thing >>>>> >>>>> Concerning the selectors with more than 2 characters, there are two >>>>> examples in use in Squeak >>>>> ==> logical implication (I use it a lot when writing tests cases) >>>>> <=> space ship operator >>>>> /// has been used in the past (but is rather deprecated) >>>>> >>>>> What is questionable is cultural acceptance of universal meaning of a >>>>> Symbol >>>>> <=> could have meant logical equivalence, but it would be pointless, >>>>> because = (and == thanks to singleton) are already equivalence. >>>>> It has been expunged from Pharo to my regrets, because it is >>>>> - beautifully self defined as < = > >>>>> - culturally legitimate >>>>> - the art of original author (Travis Griggs) >>>>> There is no sacred cow, but respect of author has a value for me. >>>>> >>>>> It's sure that every binary selector might be questionable, at least >>>>> in core image. >>>>> For application, you never know (think DSL) we can create a lot of not >>>>> completely inaesthetic ASCII styles >>>>> <|> >< <+> <-> /+/ |*| >>>>> For example +/- could be used for interval arithmetic (if we don't >>>>> want to pay the burden of typing unicode, which ain't easy) >>>>> /\ \/ intersection and union >>>>> |\| the Nicolas operator - I didn't fin a usage for it yet ;) >>>>> etc... >>>>> So why would one want to forbid them? >>>>> >>>>> For ? and ! I do not foresee elegant usage as binary, but would not >>>>> miss them as regular letters eithers. >>>>> It means accepting huge??? - understand isReallyHuge :) >>>>> huge?:or!:???and: which are not less questionable. >>>>> >>>>> Ideally, it should be really easy to define one's own syntax in any >>>>> class (already possible with own compiler/parser/scanner/whatever), or >>>>> maybe any method >>>>> I find that it's somehow more complex with the well engineered new >>>>> Compiler than it was with the very hackish legacy one, but that's a detail. >>>>> >>>>> >>>>>> and also define ^ as a binary method: >>>>>> >>>>>> "The ^ (hat) operator is used for exponentiation as well as >>>>>> conjugation by group elements, and for creating free modules of tuples and >>>>>> matrices." >>>>>> >>>>>> I'm not sure this is a good idea, because ^ is used also to return >>>>>> values. >>>>>> >>>>> >>>>> There is no ambiguity for ^ and i have proposed that in Squeak years >>>>> ago, it's a very simple change (here for legacy Compiler) >>>>> http://source.squeak.org/inbox/Compiler-nice.280.diff >>>>> >>>>> The only argument against it is that omitting the point ending last >>>>> but one sentence would not be detected as invalid syntax >>>>> >>>>> self doThis. >>>>> ^self doThat >>>>> >>>>> versus >>>>> >>>>> self doThis >>>>> ^self doThat >>>>> >>>>> To address this concern, we could have rules concerning the formatting: >>>>> normally we would write >>>>> >>>>> self doThis ^ self doThat >>>>> >>>>> or eventually if on several lines, we would generally indent >>>>> >>>>> self doThis >>>>> ^ self doThat >>>>> >>>>> An unusual formatting is a code smell IMO >>>>> And in fact, this is not much different from un-detecting when we send >>>>> a message #self when forgetting the point >>>>> >>>>> self doThis >>>>> self doThat >>>>> >>>>> self doThis self doThat. >>>>> >>>>> >>>>>> A+ >>>>>> -- >>>>>> Serge Stinckwic >>>>>> h >>>>>> >>>>>> Int. Research Unit >>>>>> on Modelling/Simulation of Complex Systems (UMMISCO) >>>>>> Sorbonne University >>>>>> (SU) >>>>>> French National Research Institute for Sustainable Development (IRD) >>>>>> U >>>>>> niversity of YaoundÃ© I, Cameroon >>>>>> "Programs must be written for people to read, and only incidentally >>>>>> for machines to execute." >>>>>> https://twitter.com/SergeStinckwich >>>>>> >>>>> >>>>

Sept. 12, 2019

Re: [Pharo-dev] I have a dream... or why I think that compatibility is an illusion and bring us to the past

by Nicolas Cellier

And to finish with ^, hare is an older implementation http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/015491.ht… And the classical refutation (we should not bother too much about it) http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/005777.ht… Le jeu. 12 sept. 2019 Ã 20:37, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > Note that I also cared to handle ^ as binary selector for Opal > Unfortunately the issue staled (for good or bad reasons, don't know...) > > > https://pharo.fogbugz.com/f/cases/13078/Allow-upArrow-caret-as-a-binary-sel… > > Le mer. 11 sept. 2019 Ã 21:21, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > >> It was just an answer to: >> >> > Do not tell me that there is a value in these selectors? >> >> I used the same argument for huge?:or!:???and: >> But I don't think it's a valid argument: it's making induction starting >> with a restricted set of examples... >> >> I also tried to answer to why and when a binary selector would be a >> "good" selector (elected for core libraries). >> (since you gave a list of selectors which were OK) >> >> I said that I don't really need ? nor ! in binary selectors, but neither >> do I in unary/keyword selectors >> (though I also thought using ? for boolean answer, I don't think it's >> really useful) >> >> >> >> Le mer. 11 sept. 2019 Ã 20:10, ducasse <stepharo(a)netcourrier.com> a >> Ã©crit : >> >>> Wait I do not understand what you are saying :) >>> I never said that I want to forbid anything. I just say that I would >>> like that ? is not consider as a part of a binary selector. >>> Amâi clearer? >>> >>> Stef >>> >>> >>> On 11 Sep 2019, at 19:48, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> Ah, and I forgot about your argumentation Stef: >>> >>> you cannot forbid binary selectors altogether because some are ugly >>> @@*+!!! (I think I read this one in Asterix le gaulois) >>> for the same reasons that >>> youCanNOtfOrBIDunaYSElectORSWIthletTersBECauSESoMeaREUgly >>> >>> Le mer. 11 sept. 2019 Ã 19:44, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : >>> >>>> >>>> >>>> Le mer. 11 sept. 2019 Ã 10:40, Serge Stinckwich < >>>> serge.stinckwich(a)gmail.com> a Ã©crit : >>>> >>>>> >>>>> >>>>> On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <g.cotelli(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Looks like Christmas season opened early this year :) >>>>>> >>>>>> Jokes aside, I'm in favor of changing some of the characters we use >>>>>> for binary selectors to allow it to be used in keyword/unary messages. >>>>>> >>>>>> I'll include % in that list. For me its more useful as a way to >>>>>> create percentages ( 5 % ) than to be used as a binary message for keeping >>>>>> an ugly name from C-like languages. >>>>>> >>>>>> - Â· is middle dot and it's used in some math operations AFAIR >>>>>> - Ã is used in math also (it's used as the multiplication sign >>>>>> for scalars, cross product for vectors and cartesian product for sets) >>>>>> >>>>>> One thing that would be really cool is that we can use the full power >>>>>> of Unicode in methods/class names. Projects like polymath and DSLs can >>>>>> clearly take advantage of that. Some examples I've just invented, but can >>>>>> be supported: >>>>>> >>>>>> >>>>>> - â from: 1 to: 5 do: [:i | i + i squared ] >>>>>> - 1 â¥ 3 >>>>>> - â anyIn: #( 1 2 4) such: [:x | x isPrime ] >>>>>> - â includes: 1 >>>>>> >>>>>> >>>>>> >>>>> Yes I would like to have something like that for PolyMath :-) >>>>> Is it possible to use Unicode characters for identifiers already ? >>>>> >>>>> I working on the port of : https://github.com/len/Domains >>>>> to Pharo. The author modify the Cuis parser, so he can do things like >>>>> that : >>>>> >>>>> "â is used for direct sums, â for tensor products, Ã for cartesian >>>>> product, direct product of groups, ring products, and in general for >>>>> categorical products." >>>>> >>>> >>>> Of course we want to be able to use those selectors: â â etc... >>>> Not using those selectors in core image is one thing, forbiding their >>>> usage for every package is another thing >>>> >>>> Concerning the selectors with more than 2 characters, there are two >>>> examples in use in Squeak >>>> ==> logical implication (I use it a lot when writing tests cases) >>>> <=> space ship operator >>>> /// has been used in the past (but is rather deprecated) >>>> >>>> What is questionable is cultural acceptance of universal meaning of a >>>> Symbol >>>> <=> could have meant logical equivalence, but it would be pointless, >>>> because = (and == thanks to singleton) are already equivalence. >>>> It has been expunged from Pharo to my regrets, because it is >>>> - beautifully self defined as < = > >>>> - culturally legitimate >>>> - the art of original author (Travis Griggs) >>>> There is no sacred cow, but respect of author has a value for me. >>>> >>>> It's sure that every binary selector might be questionable, at least in >>>> core image. >>>> For application, you never know (think DSL) we can create a lot of not >>>> completely inaesthetic ASCII styles >>>> <|> >< <+> <-> /+/ |*| >>>> For example +/- could be used for interval arithmetic (if we don't want >>>> to pay the burden of typing unicode, which ain't easy) >>>> /\ \/ intersection and union >>>> |\| the Nicolas operator - I didn't fin a usage for it yet ;) >>>> etc... >>>> So why would one want to forbid them? >>>> >>>> For ? and ! I do not foresee elegant usage as binary, but would not >>>> miss them as regular letters eithers. >>>> It means accepting huge??? - understand isReallyHuge :) >>>> huge?:or!:???and: which are not less questionable. >>>> >>>> Ideally, it should be really easy to define one's own syntax in any >>>> class (already possible with own compiler/parser/scanner/whatever), or >>>> maybe any method >>>> I find that it's somehow more complex with the well engineered new >>>> Compiler than it was with the very hackish legacy one, but that's a detail. >>>> >>>> >>>>> and also define ^ as a binary method: >>>>> >>>>> "The ^ (hat) operator is used for exponentiation as well as >>>>> conjugation by group elements, and for creating free modules of tuples and >>>>> matrices." >>>>> >>>>> I'm not sure this is a good idea, because ^ is used also to return >>>>> values. >>>>> >>>> >>>> There is no ambiguity for ^ and i have proposed that in Squeak years >>>> ago, it's a very simple change (here for legacy Compiler) >>>> http://source.squeak.org/inbox/Compiler-nice.280.diff >>>> >>>> The only argument against it is that omitting the point ending last but >>>> one sentence would not be detected as invalid syntax >>>> >>>> self doThis. >>>> ^self doThat >>>> >>>> versus >>>> >>>> self doThis >>>> ^self doThat >>>> >>>> To address this concern, we could have rules concerning the formatting: >>>> normally we would write >>>> >>>> self doThis ^ self doThat >>>> >>>> or eventually if on several lines, we would generally indent >>>> >>>> self doThis >>>> ^ self doThat >>>> >>>> An unusual formatting is a code smell IMO >>>> And in fact, this is not much different from un-detecting when we send >>>> a message #self when forgetting the point >>>> >>>> self doThis >>>> self doThat >>>> >>>> self doThis self doThat. >>>> >>>> >>>>> A+ >>>>> -- >>>>> Serge Stinckwic >>>>> h >>>>> >>>>> Int. Research Unit >>>>> on Modelling/Simulation of Complex Systems (UMMISCO) >>>>> Sorbonne University >>>>> (SU) >>>>> French National Research Institute for Sustainable Development (IRD) >>>>> U >>>>> niversity of YaoundÃ© I, Cameroon >>>>> "Programs must be written for people to read, and only incidentally >>>>> for machines to execute." >>>>> https://twitter.com/SergeStinckwich >>>>> >>>> >>>

Sept. 12, 2019

Re: [Pharo-dev] I have a dream... or why I think that compatibility is an illusion and bring us to the past

by Nicolas Cellier

Note that I also cared to handle ^ as binary selector for Opal Unfortunately the issue staled (for good or bad reasons, don't know...) https://pharo.fogbugz.com/f/cases/13078/Allow-upArrow-caret-as-a-binary-sel… Le mer. 11 sept. 2019 Ã 21:21, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : > It was just an answer to: > > > Do not tell me that there is a value in these selectors? > > I used the same argument for huge?:or!:???and: > But I don't think it's a valid argument: it's making induction starting > with a restricted set of examples... > > I also tried to answer to why and when a binary selector would be a "good" > selector (elected for core libraries). > (since you gave a list of selectors which were OK) > > I said that I don't really need ? nor ! in binary selectors, but neither > do I in unary/keyword selectors > (though I also thought using ? for boolean answer, I don't think it's > really useful) > > > > Le mer. 11 sept. 2019 Ã 20:10, ducasse <stepharo(a)netcourrier.com> a > Ã©crit : > >> Wait I do not understand what you are saying :) >> I never said that I want to forbid anything. I just say that I would like >> that ? is not consider as a part of a binary selector. >> Amâi clearer? >> >> Stef >> >> >> On 11 Sep 2019, at 19:48, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Ah, and I forgot about your argumentation Stef: >> >> you cannot forbid binary selectors altogether because some are ugly >> @@*+!!! (I think I read this one in Asterix le gaulois) >> for the same reasons that >> youCanNOtfOrBIDunaYSElectORSWIthletTersBECauSESoMeaREUgly >> >> Le mer. 11 sept. 2019 Ã 19:44, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : >> >>> >>> >>> Le mer. 11 sept. 2019 Ã 10:40, Serge Stinckwich < >>> serge.stinckwich(a)gmail.com> a Ã©crit : >>> >>>> >>>> >>>> On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <g.cotelli(a)gmail.com> >>>> wrote: >>>> >>>>> Looks like Christmas season opened early this year :) >>>>> >>>>> Jokes aside, I'm in favor of changing some of the characters we use >>>>> for binary selectors to allow it to be used in keyword/unary messages. >>>>> >>>>> I'll include % in that list. For me its more useful as a way to create >>>>> percentages ( 5 % ) than to be used as a binary message for keeping an ugly >>>>> name from C-like languages. >>>>> >>>>> - Â· is middle dot and it's used in some math operations AFAIR >>>>> - Ã is used in math also (it's used as the multiplication sign for >>>>> scalars, cross product for vectors and cartesian product for sets) >>>>> >>>>> One thing that would be really cool is that we can use the full power >>>>> of Unicode in methods/class names. Projects like polymath and DSLs can >>>>> clearly take advantage of that. Some examples I've just invented, but can >>>>> be supported: >>>>> >>>>> >>>>> - â from: 1 to: 5 do: [:i | i + i squared ] >>>>> - 1 â¥ 3 >>>>> - â anyIn: #( 1 2 4) such: [:x | x isPrime ] >>>>> - â includes: 1 >>>>> >>>>> >>>>> >>>> Yes I would like to have something like that for PolyMath :-) >>>> Is it possible to use Unicode characters for identifiers already ? >>>> >>>> I working on the port of : https://github.com/len/Domains >>>> to Pharo. The author modify the Cuis parser, so he can do things like >>>> that : >>>> >>>> "â is used for direct sums, â for tensor products, Ã for cartesian >>>> product, direct product of groups, ring products, and in general for >>>> categorical products." >>>> >>> >>> Of course we want to be able to use those selectors: â â etc... >>> Not using those selectors in core image is one thing, forbiding their >>> usage for every package is another thing >>> >>> Concerning the selectors with more than 2 characters, there are two >>> examples in use in Squeak >>> ==> logical implication (I use it a lot when writing tests cases) >>> <=> space ship operator >>> /// has been used in the past (but is rather deprecated) >>> >>> What is questionable is cultural acceptance of universal meaning of a >>> Symbol >>> <=> could have meant logical equivalence, but it would be pointless, >>> because = (and == thanks to singleton) are already equivalence. >>> It has been expunged from Pharo to my regrets, because it is >>> - beautifully self defined as < = > >>> - culturally legitimate >>> - the art of original author (Travis Griggs) >>> There is no sacred cow, but respect of author has a value for me. >>> >>> It's sure that every binary selector might be questionable, at least in >>> core image. >>> For application, you never know (think DSL) we can create a lot of not >>> completely inaesthetic ASCII styles >>> <|> >< <+> <-> /+/ |*| >>> For example +/- could be used for interval arithmetic (if we don't want >>> to pay the burden of typing unicode, which ain't easy) >>> /\ \/ intersection and union >>> |\| the Nicolas operator - I didn't fin a usage for it yet ;) >>> etc... >>> So why would one want to forbid them? >>> >>> For ? and ! I do not foresee elegant usage as binary, but would not miss >>> them as regular letters eithers. >>> It means accepting huge??? - understand isReallyHuge :) >>> huge?:or!:???and: which are not less questionable. >>> >>> Ideally, it should be really easy to define one's own syntax in any >>> class (already possible with own compiler/parser/scanner/whatever), or >>> maybe any method >>> I find that it's somehow more complex with the well engineered new >>> Compiler than it was with the very hackish legacy one, but that's a detail. >>> >>> >>>> and also define ^ as a binary method: >>>> >>>> "The ^ (hat) operator is used for exponentiation as well as conjugation >>>> by group elements, and for creating free modules of tuples and matrices." >>>> >>>> I'm not sure this is a good idea, because ^ is used also to return >>>> values. >>>> >>> >>> There is no ambiguity for ^ and i have proposed that in Squeak years >>> ago, it's a very simple change (here for legacy Compiler) >>> http://source.squeak.org/inbox/Compiler-nice.280.diff >>> >>> The only argument against it is that omitting the point ending last but >>> one sentence would not be detected as invalid syntax >>> >>> self doThis. >>> ^self doThat >>> >>> versus >>> >>> self doThis >>> ^self doThat >>> >>> To address this concern, we could have rules concerning the formatting: >>> normally we would write >>> >>> self doThis ^ self doThat >>> >>> or eventually if on several lines, we would generally indent >>> >>> self doThis >>> ^ self doThat >>> >>> An unusual formatting is a code smell IMO >>> And in fact, this is not much different from un-detecting when we send a >>> message #self when forgetting the point >>> >>> self doThis >>> self doThat >>> >>> self doThis self doThat. >>> >>> >>>> A+ >>>> -- >>>> Serge Stinckwic >>>> h >>>> >>>> Int. Research Unit >>>> on Modelling/Simulation of Complex Systems (UMMISCO) >>>> Sorbonne University >>>> (SU) >>>> French National Research Institute for Sustainable Development (IRD) >>>> U >>>> niversity of YaoundÃ© I, Cameroon >>>> "Programs must be written for people to read, and only incidentally for >>>> machines to execute." >>>> https://twitter.com/SergeStinckwich >>>> >>> >>

Sept. 12, 2019

[Pharo 8.0] Build #731: Remove somme Smalltalk references on Spec-2 example

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

There is a new Pharo build available! The status of the build #731 was: FAILURE. The Pull Request #4567 was integrated: "Remove somme Smalltalk references on Spec-2 example" Pull request url: https://github.com/pharo-project/pharo/pull/4567 Issue Url: https://github.com/pharo-project/pharo/issues/SmalltalkRemovalInSpec2Example Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 12, 2019

[Pharo 8.0] Build #730: 4544-MethodPragmaTest-triggers-code-rewrite----commit-to-repository

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

There is a new Pharo build available! The status of the build #730 was: FAILURE. The Pull Request #4568 was integrated: "4544-MethodPragmaTest-triggers-code-rewrite----commit-to-repository" Pull request url: https://github.com/pharo-project/pharo/pull/4568 Issue Url: https://github.com/pharo-project/pharo/issues/4544 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 12, 2019

[Pharo 8.0] Build #729: 4554-tagsForAllMethods-not-in-Ring

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

There is a new Pharo build available! The status of the build #729 was: FAILURE. The Pull Request #4555 was integrated: "4554-tagsForAllMethods-not-in-Ring" Pull request url: https://github.com/pharo-project/pharo/pull/4555 Issue Url: https://github.com/pharo-project/pharo/issues/4554 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 12, 2019

[Pharo 8.0] Build #728: 4552-propagateTransformation-should-not-be-subclassResponsibility

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

There is a new Pharo build available! The status of the build #728 was: FAILURE. The Pull Request #4556 was integrated: "4552-propagateTransformation-should-not-be-subclassResponsibility" Pull request url: https://github.com/pharo-project/pharo/pull/4556 Issue Url: https://github.com/pharo-project/pharo/issues/4552 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 12, 2019