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
>

Reply via email to