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-selector Le mer. 11 sept. 2019 à 21:21, Nicolas Cellier < [email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 < >> [email protected]> a écrit : >> >>> >>> >>> Le mer. 11 sept. 2019 à 10:40, Serge Stinckwich < >>> [email protected]> a écrit : >>> >>>> >>>> >>>> On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <[email protected]> >>>> 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 >>>> >>> >>
