Le 26 juin 2014 à 12:46, Nicolas Cellier a écrit :

$! is not classified as a binary character right now, is it? Of course it's possible but I'd just say why this particular symbol? It does not look mathematical either. Or do you love C/C++ so much?

Of course not. It is just because it is something widely used but other names could do the stuff like <> or /=

Note that ~= has same meaning in Matlab.

There are other possibilities like /= or <> (Fortran 95, ADA), even the long form =/=.

But frankly, I don't buy this kind of change, for the sake of looking like some {} language, making such a deep change is overkill.

Indeed it is a deep change but maybe at least we could have an alias and use it for all new code. At a time, it will be less painful to do this change. As expressed in another thread, Smalltalk code convention for method naming strategy is intention revealing. That said, I think ~= is not intention revealing and it will be good to fix or propose a good alternative.

2014-06-26 13:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:

I think that while working with float arithmetic it will be nice to provide something like #~= instead of #closeTo:, and also add #~<, #~<= and so on. But maybe I’m wrong :)

Uko

Yes, it's wrong because there is no such thing as a universal tolerance. We need at least two parameters.

On 26 Jun 2014, at 13:07, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:

Le 26 juin 2014 à 12:46, Nicolas Cellier a écrit :

$! is not classified as a binary character right now, is it? Of course it's possible but I'd just say why this particular symbol? It does not look mathematical either. Or do you love C/C++ so much?

Of course not. It is just because it is something widely used but other names could do the stuff like <> or /=

Note that ~= has same meaning in Matlab.

There are other possibilities like /= or <> (Fortran 95, ADA), even the long form =/=.

But frankly, I don't buy this kind of change, for the sake of looking like some {} language, making such a deep change is overkill.

Indeed it is a deep change but maybe at least we could have an alias and use it for all new code. At a time, it will be less painful to do this change. As expressed in another thread, Smalltalk code convention for method naming strategy is *intention revealing*. That said, I think ~= is not intention revealing and it will be good to fix or propose a good alternative.

;) On 26/6/14 12:46, Nicolas Cellier wrote:

$! is not classified as a binary character right now, is it? Of course it's possible but I'd just say why this particular symbol? It does not look mathematical either. Or do you love C/C++ so much?

Note that ~= has same meaning in Matlab.

There are other possibilities like /= or <> (Fortran 95, ADA), even the long form =/=.

But frankly, I don't buy this kind of change, for the sake of looking like some {} language, making such a deep change is overkill.

In any case, a big -1 for !=

lol :D On Thu, Jun 26, 2014 at 8:03 PM, Norbert Hartl <norbert@hartl.name> wrote:

Am 26.06.2014 um 12:46 schrieb Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:

$! is not classified as a binary character right now, is it? Of course it's possible but I'd just say why this particular symbol? It does not look mathematical either. Or do you love C/C++ so much?

Note that ~= has same meaning in Matlab.

There are other possibilities like /= or <> (Fortran 95, ADA), even the long form =/=.

But frankly, I don't buy this kind of change, for the sake of looking like some {} language, making such a deep change is overkill.

In any case, a big -1 for !=

+1 ... hmmm err... I mean -1...hmmm ok +1 for the -1. Ok, I guess I suck at math.

Norbert

2014-06-26 10:47 GMT+02:00 Max Leske <maxleske@gmail.com>:

...

On 26.06.2014, at 10:15, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:

...

Hi,

I would like to make a suggestion that may lead to a long debate but let's go: What do you think about deprecating ~= and replace it with != for example? Why? In mathematics the symbol ~ is used for equivalence. To me (and I think any newcomer to Smalltalk) the first guess of the meaning of ~= is equivalent to => missed. The meaning is totally different: "Answer whether the receiver and the argument do not represent the same object.”

+1 But then I also want to suggest #!== for negating identity.

...

I never used this method because it is too confusing for me. I prefer

to use (a = b) not or (a = b) ifFalse:.

...

So, the discussion is open ...

Christophe

On Thu, Jun 26, 2014 at 11:29 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

For me ~ looks more like closeTo:

so you also agree then -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

On 26 Jun 2014, at 13:27, Sven Van Caekenberghe <sven@stfx.eu> wrote:

-1 for replacing ~= with != because it is not better at all +1 for avoiding it altogether like you suggest -1 for changing ~= to mean #closeTo: I like the longer name

Yes, but this way we can end up with the names like: #lessThanOrCloseTo: :)

my 2c

On 26 Jun 2014, at 10:15, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:

...

Hi,

I would like to make a suggestion that may lead to a long debate but let's go: What do you think about deprecating ~= and replace it with != for example? Why? In mathematics the symbol ~ is used for equivalence. To me (and I think any newcomer to Smalltalk) the first guess of the meaning of ~= is equivalent to => missed. The meaning is totally different: "Answer whether the receiver and the argument do not represent the same object."

I never used this method because it is too confusing for me. I prefer to use (a = b) not or (a = b) ifFalse:. So, the discussion is open ...

Christophe

Can the parser parse != ? Can the parser parse ! ? Both for Opal and the old Compiler ? Clement 2014-06-26 13:56 GMT+02:00 Christophe Demarey <Christophe.Demarey@inria.fr>:

!= does not look a good name according to first feedbacks. A long version could simply be notEquals: For a short version, more opinions/suggestions are welcomed

Le 26 juin 2014 à 13:27, Sven Van Caekenberghe a écrit :

...

-1 for replacing ~= with != because it is not better at all +1 for avoiding it altogether like you suggest -1 for changing ~= to mean #closeTo: I like the longer name

my 2c

On 26 Jun 2014, at 10:15, Christophe Demarey < Christophe.Demarey@inria.fr> wrote:

...

Hi,

I would like to make a suggestion that may lead to a long debate but let's go: What do you think about deprecating ~= and replace it with != for example? Why? In mathematics the symbol ~ is used for equivalence. To me (and I think any newcomer to Smalltalk) the first guess of the meaning of ~= is equivalent to => missed. The meaning is totally different: "Answer whether the receiver and the argument do not represent the same object."

I never used this method because it is too confusing for me. I prefer to use (a = b) not or (a = b) ifFalse:. So, the discussion is open ...

Christophe

Esteban A. Maringolo wrote

If one thing confuses people in that realm is non arithmetic precedence: Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.

And we're not going to change that either. It's not worthy, and I doubt if it is possible at all.

I'm probably late to the party with this reply. The primary reason for not changing this is that it would be incorrect. It comes down to intrinsic versus extrinsic meaning. A multiple operator has an intrinsic meaning: it means multiple. But a message name does not have intrinsic meaning (other than it is a good idea to have the name represent what it does). The meaning of a message is determined by the receiver. e.g. if PetitParser defines #* to mean "0 or more repetitions", what happens when someone has decided that it should be evaluated before #+? Message sending precedence can only be defined in terms of the type of message: unary, binary (or infix), and keyword, since the interpretation of the message is the receiver's responsibility, not the compiler's. -- View this message in context: http://forum.world.st/about-tp4764892p4765070.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Couldn't we just have an expression evaluator done with PetitParser doing these things? Tcl and Bash have this expr: thing. (Expression parse: '5+3*2') value. (Expression parse: ':a | 5+:a*2') value:10. (Expression parse: ':a | 5+:a*2') value:self x. With the thesis of Lukas Renggli these was this Helvetia story. Is there any chance we see something around these lines now that there is a new compiler thing inside Pharo? So: someMethod: anX <expr> ^ 5 + anX * 2 Phil On Thu, Jun 26, 2014 at 6:11 PM, Richard Sargent < richard.sargent@gemtalksystems.com> wrote:

Esteban A. Maringolo wrote

...

If one thing confuses people in that realm is non arithmetic precedence: Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.

And we're not going to change that either. It's not worthy, and I doubt if it is possible at all.

I'm probably late to the party with this reply. The primary reason for not changing this is that it would be incorrect. It comes down to intrinsic versus extrinsic meaning. A multiple operator has an intrinsic meaning: it means multiple. But a message name does not have intrinsic meaning (other than it is a good idea to have the name represent what it does). The meaning of a message is determined by the receiver. e.g. if PetitParser defines #* to mean "0 or more repetitions", what happens when someone has decided that it should be evaluated before #+?

Message sending precedence can only be defined in terms of the type of message: unary, binary (or infix), and keyword, since the interpretation of the message is the receiver's responsibility, not the compiler's.

-- View this message in context: http://forum.world.st/about-tp4764892p4765070.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Le 26/06/2014 18:11, Richard Sargent a écrit :

Esteban A. Maringolo wrote

...

If one thing confuses people in that realm is non arithmetic precedence: Eg. 2 + 3 * 4 = 20 instead of the "expected" 14.

And we're not going to change that either. It's not worthy, and I doubt if it is possible at all.

I'm probably late to the party with this reply. The primary reason for not changing this is that it would be incorrect. It comes down to intrinsic versus extrinsic meaning. A multiple operator has an intrinsic meaning: it means multiple. But a message name does not have intrinsic meaning (other than it is a good idea to have the name represent what it does). The meaning of a message is determined by the receiver. e.g. if PetitParser defines #* to mean "0 or more repetitions", what happens when someone has decided that it should be evaluated before #+?

Message sending precedence can only be defined in terms of the type of message: unary, binary (or infix), and keyword, since the interpretation of the message is the receiver's responsibility, not the compiler's.

You could do it, but then you would have to wire the smalltalk parser with additional data (binary messages precedence) that would have to add a way or another to your binary method definition. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95