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.n...@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.n...@gmail.com > <mailto:nicolas.cellier.aka.n...@gmail.com>> a écrit : > > > Le mer. 11 sept. 2019 à 10:40, Serge Stinckwich <serge.stinckw...@gmail.com > <mailto:serge.stinckw...@gmail.com>> a écrit : > > > On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <g.cote...@gmail.com > <mailto:g.cote...@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 > <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 > <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 Stinckwich > Int. Research Unit on Modelling/Simulation of Complex Systems (UMMISCO) > Sorbonne University (SU) > French National Research Institute for Sustainable Development (IRD) > University of Yaoundé I, Cameroon > "Programs must be written for people to read, and only incidentally for > machines to execute." > https://twitter.com/SergeStinckwich <https://twitter.com/SergeStinckwich>
