Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is. Indeed there is no ambiguity, since the return ^ is always prefixed, while a binary message never is... (well, except in the method source, but method source must begin with selector, it cannot begin with a return statement, so no ambinguity there neither...).
I don't plan to use or add such selector in core Squeak/Pharo, but I think that it is important to allow a variety of selectors : it allows the most simple DSL : one using Smalltalk syntax (no need to define a new syntax, a new parser, etc...). If we did it for |, I don't see why we shouldn't for ^. Note that we recently also extended usage of - at any place in binary selectors (it was restricted to first position previously), though no core message is concerned so far.
The main objection could be that a missing period before a return statement won't be reported, but interpreted as a message send... like in: x := a+b ^x
But I don't think it's really a feature stopper.
It's very easy to modify the old Compiler and shouldn't be that hard in Opal too. I'll try and push a prototype in Squeak inbox this evening.
What do you think?
On 24.02.2014, at 19:52, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is. Indeed there is no ambiguity, since the return ^ is always prefixed, while a binary message never is... (well, except in the method source, but method source must begin with selector, it cannot begin with a return statement, so no ambinguity there neither...).
I don't plan to use or add such selector in core Squeak/Pharo, but I think that it is important to allow a variety of selectors : it allows the most simple DSL : one using Smalltalk syntax (no need to define a new syntax, a new parser, etc...). If we did it for |, I don't see why we shouldn't for ^. Note that we recently also extended usage of - at any place in binary selectors (it was restricted to first position previously), though no core message is concerned so far.
The main objection could be that a missing period before a return statement won't be reported, but interpreted as a message send... like in: x := a+b ^x
But I don't think it's really a feature stopper.
It's very easy to modify the old Compiler and shouldn't be that hard in Opal too. I'll try and push a prototype in Squeak inbox this evening.
What do you think?
^ ^ v v < > < > b a.
Best -Tobias
On 24-02-2014, at 10:52 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is.
[snip]
What do you think?
I think that it would be a massive cognitive overload when reading code. The return signifier needs to be a unique artefact, whatever it is.
foo bar blah ^ ribbet factorial
Quick - is that correct code or should there be a ‘.’ in front of the ^ ? Will it crash the spaceship?
I wish we still had a proper up arrow rather than a caret, not to mention the proper left arrow assign instead of the nonsensical Pascal :=.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin
Quoting tim Rowledge tim@rowledge.org:
On 24-02-2014, at 10:52 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is.
[snip]
What do you think?
I think that it would be a massive cognitive overload when reading code. The return signifier needs to be a unique artefact, whatever it is.
foo bar blah ^ ribbet factorial
Quick - is that correct code or should there be a ‘.’ in front of the ^ ? Will it crash the spaceship?
I wish we still had a proper up arrow rather than a caret, not to mention the proper left arrow assign instead of the nonsensical Pascal :=.
StrikeFont allInstancesDo: [ :each | each useLeftArrow ]
:)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin
Cheers, Juan Vuletich
On Mon, 24 Feb 2014, J. Vuletich (mail lists) wrote:
Quoting tim Rowledge tim@rowledge.org:
On 24-02-2014, at 10:52 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is.
[snip]
What do you think?
I think that it would be a massive cognitive overload when reading code. The return signifier needs to be a unique artefact, whatever it is.
foo bar blah ^ ribbet factorial
Quick - is that correct code or should there be a ‘.’ in front of the ^ ? Will it crash the spaceship?
I wish we still had a proper up arrow rather than a caret, not to mention the proper left arrow assign instead of the nonsensical Pascal :=.
StrikeFont allInstancesDo: [ :each | each useLeftArrow ]
That solves the problem, but it makes another. We lose underscore character with that change. :)
Levente
:)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin
Cheers, Juan Vuletich
Ah, the sacrificial underscore. I like the left arrow and the up arrow a lot, but I see how this could mess one up when one has code with underscores in it.
I don't have any code with underscores in it. They don't seem to fit the language stylistically to my eye.
On Tue, Feb 25, 2014 at 2:13 PM, Levente Uzonyi leves@elte.hu wrote:
On Mon, 24 Feb 2014, J. Vuletich (mail lists) wrote:
Quoting tim Rowledge tim@rowledge.org:
On 24-02-2014, at 10:52 AM, Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com> wrote:
Though being reserved for return statements, the upArrow ^ could
perfectly be accepted as a character composing a binary selector, like the verticalBar | already is.
[snip]
What do you think?
I think that it would be a massive cognitive overload when reading
code. The return signifier needs to be a unique artefact, whatever it is.
foo bar blah ^ ribbet factorial
Quick - is that correct code or should there be a '.' in front of the ^ ? Will it crash the spaceship?
I wish we still had a proper up arrow rather than a caret, not to mention the proper left arrow assign instead of the nonsensical Pascal :=.
StrikeFont allInstancesDo: [ :each | each useLeftArrow ]
That solves the problem, but it makes another. We lose underscore character with that change. :)
Levente
:)
tim
-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin
Cheers, Juan Vuletich
2014-02-25 20:52 GMT-03:00 Casey Ransberger casey.obrien.r@gmail.com:
I don't have any code with underscores in it. They don't seem to fit the language stylistically to my eye.
+1
On 25 February 2014 15:52, Casey Ransberger casey.obrien.r@gmail.com wrote:
Ah, the sacrificial underscore. I like the left arrow and the up arrow a lot, but I see how this could mess one up when one has code with underscores in it.
I don't have any code with underscores in it. They don't seem to fit the language stylistically to my eye.
Ah, but which one? Underscore as assignment? Or selectors with underscores?
(My personal vote? Big fat -1 on underscore-as-assignment: I think it's really ugly. +1 on underscore-in-selector, because I like the freedom, and because it reduces pain when working with underscore_using_languages.
I like names like "slot-value", but we're not writing lisp here...)
frank
On Tue, Feb 25, 2014 at 2:13 PM, Levente Uzonyi leves@elte.hu wrote:
On Mon, 24 Feb 2014, J. Vuletich (mail lists) wrote:
Quoting tim Rowledge tim@rowledge.org:
On 24-02-2014, at 10:52 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is.
[snip]
What do you think?
I think that it would be a massive cognitive overload when reading code. The return signifier needs to be a unique artefact, whatever it is.
foo bar blah ^ ribbet factorial
Quick - is that correct code or should there be a ‘.’ in front of the ^ ? Will it crash the spaceship?
I wish we still had a proper up arrow rather than a caret, not to mention the proper left arrow assign instead of the nonsensical Pascal :=.
StrikeFont allInstancesDo: [ :each | each useLeftArrow ]
That solves the problem, but it makes another. We lose underscore character with that change. :)
Levente
:)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one? -- Tom Cargin
Cheers, Juan Vuletich
I had a whole lot of stuff typed but really it boils down to something simple. We need at least one symbol within the common character set that we can use as a syntactic element not related to a typical character - a return token. I’d like to go back to having another for the assignment, given my druthers. If we use the same symbol/character for both the return token and in general names then I think we are likely to get confused at some point and Murphy requires that it will be during some really inconvenient time.
So, all in all, I suggest not using ^ in general names.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Recedite, plebes! Gero rem imperialem! = Stand aside plebians! I am on imperial business.
On 26.02.2014, at 21:39, tim Rowledge tim@rowledge.org wrote:
I had a whole lot of stuff typed but really it boils down to something simple. We need at least one symbol within the common character set that we can use as a syntactic element not related to a typical character - a return token.
Don’t get me wrong, but how do you come to the conclusion “We need [paraphrased: a distinct] return token”? I mean, all other languages do without it, no? I don’t want to say, we want to be like others, but apparently, we (Smalltalk family, w/ Self etc.) are lonesome single-charcter return token users, aren’t we? (Not that this would be wrong) So again, why do we need it explicitly?
I’d like to go back to having another for the assignment, given my druthers. If we use the same symbol/character for both the return token and in general names then I think we are likely to get confused at some point and Murphy requires that it will be during some really inconvenient time.
So, all in all, I suggest not using ^ in general names.
Best -Tobias
On 26-02-2014, at 2:02 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 26.02.2014, at 21:39, tim Rowledge tim@rowledge.org wrote:
I had a whole lot of stuff typed but really it boils down to something simple. We need at least one symbol within the common character set that we can use as a syntactic element not related to a typical character - a return token.
Don’t get me wrong, but how do you come to the conclusion “We need [paraphrased: a distinct] return token”? I mean, all other languages do without it, no?
C/Pascal/others use the return token ‘return’ spelled out. Those languages have a large complex syntax with ugly precedence rules so complex they need wall posters to list them all. In that context using a whole word seems a relatively minor crime. Smalltalk is simple. I like simple.
I don’t want to say, we want to be like others, but apparently, we (Smalltalk family, w/ Self etc.) are lonesome single-charcter return token users, aren’t we? (Not that this would be wrong) So again, why do we need it explicitly?
Because that is how Smalltalk is. If we tried to use ‘return’, how would that read?
foo: aNumber |temp| temp := 4 + aNumber. return temp - that looks both ugly and annoying to parse.
foo: aNumber |temp| temp := 4 + aNumber. temp return - a little less ugly to read, and it even looks like a message send but implementation would be fairly nasty. Something like return thisContext sender returnValue: self
Yuck. How about we don’t break something that works nicely?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim An algorithm must be seen to be believed.
Hi,
I flag this OT, since I just fool around in the following.
On 26.02.2014, at 23:19, tim Rowledge tim@rowledge.org wrote:
On 26-02-2014, at 2:02 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 26.02.2014, at 21:39, tim Rowledge tim@rowledge.org wrote:
I had a whole lot of stuff typed but really it boils down to something simple. We need at least one symbol within the common character set that we can use as a syntactic element not related to a typical character - a return token.
Don’t get me wrong, but how do you come to the conclusion “We need [paraphrased: a distinct] return token”? I mean, all other languages do without it, no?
C/Pascal/others use the return token ‘return’ spelled out. Those languages have a large complex syntax with ugly precedence rules so complex they need wall posters to list them all. In that context using a whole word seems a relatively minor crime. Smalltalk is simple. I like simple.
As do I.
I don’t want to say, we want to be like others, but apparently, we (Smalltalk family, w/ Self etc.) are lonesome single-charcter return token users, aren’t we? (Not that this would be wrong) So again, why do we need it explicitly?
Because that is how Smalltalk is. If we tried to use ‘return’, how would that read?
foo: aNumber |temp| temp := 4 + aNumber. return temp
- that looks both ugly and annoying to parse.
foo: aNumber |temp| temp := 4 + aNumber. temp return
- a little less ugly to read, and it even looks like a message send but implementation would be fairly nasty. Something like
return thisContext sender returnValue: self
Yuck. How about we don’t break something that works nicely?
Ok, I got your line of thought :) I don’t want a 'return' statement either, and retain ^ or ↑ as return character.
but as it stands, you just proved that it is not necessary de facto ;)
ATTENTION: NO proposal ahead, just thinking:
First, for normal methods, we can do without any return statement, just by saying: The last expression of a method constitutes its return value. Fromt the example:
foo: aNumber |temp| temp := 4 + aNumber. temp
Second, for other returns as in:
burp: aNumber aNumber > 3 ifTrue: [^3]. ^ 2.
, it is always possible to transform such “multi-path” methods (cyclomatic complexity > 1) into methods with just one return. Granted: a number of them will look uglier than before :)
Methods returning nothing would then have to state self explicitly:
knorz self doSometingKnorzy. self. "or self yourself, for increased hilarity"
The only actual _explicit_ return necessary is hence the non-local one as in:
nerf [self killRandomProccess] on: PermissionError do: [^ 'too bad']
But you just gave a solution for that one with the #returnValue trick. I think the link Jecel provided is a good read for such foolery :)
Best and good night -Tobias
PS: I really like to write 2^31 - 1 and have it be valid Smalltalk…
On 26-02-2014, at 2:36 PM, Tobias Pape Das.Linux@gmx.de wrote:
I flag this OT, since I just fool around in the following.
You are a clever, tricky, and probably dangerous person. Congratulations :-)
PS: I really like to write 2^31 - 1 and have it be valid Smalltalk…
I see the attraction.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim An algorithm must be seen to be believed.
On 26.02.2014, at 23:40, tim Rowledge tim@rowledge.org wrote:
On 26-02-2014, at 2:36 PM, Tobias Pape Das.Linux@gmx.de wrote:
I flag this OT, since I just fool around in the following.
You are a clever, tricky, and probably dangerous person. Congratulations :-)
Well probably only the last, as I lack the first two ones ;)
PS: I really like to write 2^31 - 1 and have it be valid Smalltalk…
I see the attraction.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim An algorithm must be seen to be believed.
Am 26.02.2014 um 23:36 schrieb Tobias Pape Das.Linux@gmx.de:
PS: I really like to write 2^31 - 1 and have it be valid Smalltalk…
You could easily write it the Fortran way: 2**31 - 1
Kind regards Georg
2014-02-27 9:05 GMT+01:00 Georg Gollmann gollmann@zid.tuwien.ac.at:
Am 26.02.2014 um 23:36 schrieb Tobias Pape Das.Linux@gmx.de:
PS: I really like to write 2^31 - 1 and have it be valid Smalltalk...
You could easily write it the Fortran way: 2**31 - 1
Kind regards Georg
Or if it's just 2 you want to raise, the highly obfuscated 1<<31 - 1
already work in Squeak ;)
On 26 February 2014 14:19, tim Rowledge tim@rowledge.org wrote:
On 26-02-2014, at 2:02 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 26.02.2014, at 21:39, tim Rowledge tim@rowledge.org wrote:
I had a whole lot of stuff typed but really it boils down to something simple. We need at least one symbol within the common character set that we can use as a syntactic element not related to a typical character - a return token.
Don’t get me wrong, but how do you come to the conclusion “We need [paraphrased: a distinct] return token”? I mean, all other languages do without it, no?
C/Pascal/others use the return token ‘return’ spelled out. Those languages have a large complex syntax with ugly precedence rules so complex they need wall posters to list them all. In that context using a whole word seems a relatively minor crime. Smalltalk is simple. I like simple.
C yes, Pascal no. In Pascal you assign to a pseudovariable called Result. For the record I am totally OK with the three keypresses involved in typing ":=". It should be even longer, because assignment is evil (*), and if you assign you should be punished. (This is why a cast in Scala is called "asInstanceOf". It's deliberately ugly and painful to write to make you avoid it.) But that's just me.
I don’t want to say, we want to be like others, but apparently, we (Smalltalk family, w/ Self etc.) are lonesome single-charcter return token users, aren’t we? (Not that this would be wrong) So again, why do we need it explicitly?
Because that is how Smalltalk is. If we tried to use ‘return’, how would that read?
foo: aNumber |temp| temp := 4 + aNumber. return temp
- that looks both ugly and annoying to parse.
foo: aNumber |temp| temp := 4 + aNumber. temp return
- a little less ugly to read, and it even looks like a message send but implementation would be fairly nasty. Something like
return thisContext sender returnValue: self
Yuck. How about we don’t break something that works nicely?
I don't understand why you're even saying this. No one is suggesting adding a new keyword. No one is suggesting breaking anything. We're talking about allowing ^ as a perfectly sensible binary selector. Now the last time someone suggested a seemingly minor grammatical change, it turned out to have nasty effects elsewhere in the grammar. _If that's the case_ we shouldn't allow ^ as a binary selector. But someone needs to actually do the due diligence, and see what happens. We know of one case where a syntactic error turns into an unexpected message send. I'm OK with that, if that's the only fallout. You should have written a test for the method.
frank
(*) If you need gospel to back up this seeming heresy, go grep for "assignment" in The Early History of Smalltalk, written by some guy we might have heard of, here and there.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim An algorithm must be seen to be believed.
Below
On Feb 26, 2014, at 9:45 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 25 February 2014 15:52, Casey Ransberger casey.obrien.r@gmail.com wrote: Ah, the sacrificial underscore. I like the left arrow and the up arrow a lot, but I see how this could mess one up when one has code with underscores in it.
I don't have any code with underscores in it. They don't seem to fit the language stylistically to my eye.
Ah, but which one? Underscore as assignment? Or selectors with underscores?
(My personal vote? Big fat -1 on underscore-as-assignment: I think it's really ugly. +1 on underscore-in-selector, because I like the freedom, and because it reduces pain when working with underscore_using_languages.
I like names like "slot-value", but we're not writing lisp here...)
frank
To clarify: I prefer "underscore" assignment to the Pascal style, but I use the left arrow glyph, not the underscore glyph, so my code hasn't got any underscores in it:P
(big snip)
Quoting Levente Uzonyi leves@elte.hu:
On Mon, 24 Feb 2014, J. Vuletich (mail lists) wrote:
Quoting tim Rowledge tim@rowledge.org:
...
I wish we still had a proper up arrow rather than a caret, not to mention the proper left arrow assign instead of the nonsensical Pascal :=.
StrikeFont allInstancesDo: [ :each | each useLeftArrow ]
That solves the problem, but it makes another. We lose underscore character with that change. :)
Levente
:)
Well, yes. Another possibility that might please some is to use Shout. At least in Cuis, Shout can show all assignments as underscore/leftArrow or as ':=' (or just let them alone).
It wouldn't be hard to tweak this to show the proper code point for left arrow, or an unused 8-bit character code, binding it to the left arrow glyph. In that way, regardless of the user typing '_' or ':=', when method is saved, it would be shown as left arrow.
(Another tweak is needed. When modifying existing code, this new character would in the source code instead of '_' or ':=', so it is needed to tweak the parser to accept it.)
That would give, at the same time, underscores for C lovers and left arrow assignments for classic Smalltalk lovers. Maybe people in both groups would like it.
Cheers, Juan Vuletich
On 28-02-2014, at 5:07 AM, J. Vuletich (mail lists) juanlists@jvuletich.org wrote:
Well, yes. Another possibility that might please some is to use Shout. At least in Cuis, Shout can show all assignments as underscore/leftArrow or as ':=' (or just let them alone).
That’s a nice idea. It would even have the side-benefit of making me see the point of Shout…
I don’t imagine it would be much more difficult to do something with the ^, displaying a nice arrow when it will be interpreted as a return and ^ if it is seen as a message-part.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Kzin does it take to change a lightbulb?" "None. You can scream and leap in the dark."
On 24 Feb 2014, at 19:52, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is. Indeed there is no ambiguity, since the return ^ is always prefixed, while a binary message never is... (well, except in the method source, but method source must begin with selector, it cannot begin with a return statement, so no ambinguity there neither...).
I don't plan to use or add such selector in core Squeak/Pharo, but I think that it is important to allow a variety of selectors : it allows the most simple DSL : one using Smalltalk syntax (no need to define a new syntax, a new parser, etc...). If we did it for |, I don't see why we shouldn't for ^. Note that we recently also extended usage of - at any place in binary selectors (it was restricted to first position previously), though no core message is concerned so far.
The main objection could be that a missing period before a return statement won't be reported, but interpreted as a message send... like in: x := a+b ^x
But I don't think it's really a feature stopper.
It's very easy to modify the old Compiler and shouldn't be that hard in Opal too. I'll try and push a prototype in Squeak inbox this evening.
What do you think?
+1
flexibility is always good :-) You never know what people want to build later. The base level should be extremely flexible (to the point that to you can break *any* Smalltalk convention). Any kind of checks for “best practices” should be done on level up on the tool level, and even there only if really needed. (in the past we had the idea to provide feedback e.g. to not have instance variables with capital letters, but this should *never* be enforced on the low level, as for DSLs, research hacks and real cool stuff (TM) people need all flexibility)
Pharo uses (right now) RBParser as the main Parser… in Pharo4 we will remove the old Parser (subclass of Scanner ;-), on the TODO is to check if PetitParser can be used instead (but there are many open questions related to e.g. error handling, speed…)
Marcus
Pharo uses (right now) RBParser as the main Parser… in Pharo4 we will remove the old Parser (subclass of Scanner ;-),
Other first plans (we need to start a real discussion after Pharo3 is released) for Pharo4 are in the in the Fosdem talk:
Slides: http://www.slideshare.net/MarcusDenker/2013-fosdempharo4 Video: https://www.youtube.com/watch?v=mUV9E03u52g
I think even this change should wait for Pharo4… but of course it can be prepared and ready for inclusion. (we need to be a bit careful what to change now, the side-effects of changes are always amazing ;-)
Marcus
2014-02-24 20:22 GMT+01:00 Marcus Denker marcus.denker@inria.fr:
Pharo uses (right now) RBParser as the main Parser... in Pharo4 we will
remove the old Parser (subclass of Scanner ;-),
Other first plans (we need to start a real discussion after Pharo3 is released) for Pharo4 are in the in the Fosdem talk:
Slides: http://www.slideshare.net/MarcusDenker/2013-fosdempharo4 Video: https://www.youtube.com/watch?v=mUV9E03u52g
I think even this change should wait for Pharo4... but of course it can be prepared and ready for inclusion. (we need to be a bit careful what to change now, the side-effects of changes are always amazing ;-)
Marcus
Fully agree, not a candidate for inclusion in 3.0 in any case.
On 24 February 2014 10:52, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Though being reserved for return statements, the upArrow ^ could perfectly be accepted as a character composing a binary selector, like the verticalBar | already is. Indeed there is no ambiguity, since the return ^ is always prefixed, while a binary message never is... (well, except in the method source, but method source must begin with selector, it cannot begin with a return statement, so no ambinguity there neither...).
I don't plan to use or add such selector in core Squeak/Pharo, but I think that it is important to allow a variety of selectors : it allows the most simple DSL : one using Smalltalk syntax (no need to define a new syntax, a new parser, etc...). If we did it for |, I don't see why we shouldn't for ^. Note that we recently also extended usage of - at any place in binary selectors (it was restricted to first position previously), though no core message is concerned so far.
The main objection could be that a missing period before a return statement won't be reported, but interpreted as a message send... like in: x := a+b ^x
But I don't think it's really a feature stopper.
It's very easy to modify the old Compiler and shouldn't be that hard in Opal too. I'll try and push a prototype in Squeak inbox this evening.
What do you think?
I think that I should read _all_ my mail before repyling. I mildly in favour of allowing ^ as a binary selector. It would be nice if we could automatically infer the impact of seemingly minor grammatical changes like this, and sniff out newly introduced ambiguities and such.
frank
squeak-dev@lists.squeakfoundation.org
-
Casey Ransberger -
Frank Shearar -
Georg Gollmann -
Germán Arduino -
J. Vuletich (mail lists) -
Levente Uzonyi -
Marcus Denker -
Nicolas Cellier -
tim Rowledge -
Tobias Pape