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> a écrit :

>
>
> Le mer. 11 sept. 2019 à 10:40, Serge Stinckwich <
> serge.stinckw...@gmail.com> a écrit :
>
>>
>>
>> On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <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
>> 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
>>
>

Reply via email to