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