I have a dream... or why I think that compatibility is an illusion and bring us to the past

On 12 Sep 2019, at 21:57, Nicolas Cellier <[hidden email]> wrote:

Funnily, in same period you could find defenders of ? in binary selectors:

http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/008893.html

and more geenral discussion about binary selectors:

http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/001466.html

Stef, u gonna hate me for living in the past ;)

But you don't have to be stuck of course :)

Le jeu. 12 sept. 2019 à 21:39, Nicolas Cellier <[hidden email]> a écrit :

And to finish with ^, hare is an older implementation

http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/015491.html

And the classical refutation (we should not bother too much about it)

http://lists.squeakfoundation.org/pipermail/squeak-dev/1999-March/005777.html

Le jeu. 12 sept. 2019 à 20:37, Nicolas Cellier <[hidden email]> a écrit :

Note that I also cared to handle ^ as binary selector for Opal

Unfortunately the issue staled (for good or bad reasons, don't know...)

https://pharo.fogbugz.com/f/cases/13078/Allow-upArrow-caret-as-a-binary-selector

Le mer. 11 sept. 2019 à 21:21, Nicolas Cellier <[hidden email]> a écrit :

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> a écrit :

Le mer. 11 sept. 2019 à 10:40, Serge Stinckwich <[hidden email]> a écrit :

On Wed, Sep 11, 2019 at 2:14 AM Gabriel Cotelli <[hidden email]> 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

On Wed, 11 Sep 2019 at 15:10, ducasse <[hidden email]> wrote:

> On 11 Sep 2019, at 04:07, James Foster <[hidden email]> wrote:
>
> Would use of ? and ! in unary/keyword selectors be convention or somehow required? If simply convention, then we should start with renaming testing methods to be named is* or has*.
>       flag1 := anInteger even.                “not good"

Agreed.  That could "almost" be construed  as converting a 3 to a 2 or 4.

 

>       flag2 := anInteger isEven.      “better"

Agreed. It reads well.

 

>       flag3 := anInteger even?.       “how much better?”

For me, this doesn't read as well as flag2, but even though there is some redundancy, for me a combination reads well...

     flag3a := anInteger isEven?

Perhaps if "?"==>Boolean was a strong convention then there could be a check when the value is returned rather than when it is used (or would that complicate other things?) 

 

>       flag4 := #(1 2 3) includes?: 2. “how much better?”

My first impression is "yuck!", but then I think... "maybe" if there was a definite benefit (i.e. optimization) from strong guarantees about the return value being Boolean.

 

I think that I would use ? mainly for unary message

Now I’m sure that if you look carefully some people use

        include
                for the action
        includes
                for the tests

I took include as an example and this is super not intention revealing.

>> lineUpBlockBrackets

        lineUpBlockBrackets?
        Now I will rewrite them all as shouldLineUpBlockBrackets or isLineUpBlockBrackets and to me for unary message ? makes it a lot better.

btw, some alternatives...  

    doBlockBracketsLineUp   - reads well but "do" is already a loaded word

    areBlockBracketsLinedUp - reads well with the past-tense phrasing

cheers -ben