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 >>> >> >
