Authorize upArrow in binary symbols

On 24.02.2014, at 19:52, Nicolas Cellier <[hidden email]> wrote:
^ ^ v v < > < > b a.

Best
        -Tobias

On 24-02-2014, at 10:52 AM, Nicolas Cellier <[hidden email]> 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; [hidden email]; 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

On 24 Feb 2014, at 19:52, Nicolas Cellier <[hidden email]> wrote:


+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

Quoting tim Rowledge <[hidden email]>:

StrikeFont allInstancesDo: [ :each | each useLeftArrow ]

:)

> tim
> --
> tim Rowledge; [hidden email]; 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 24 February 2014 10:52, Nicolas Cellier
<[hidden email]> wrote:
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

On Mon, 24 Feb 2014, J. Vuletich (mail lists) wrote:
That solves the problem, but it makes another. We lose underscore
character with that change. :)


Levente

On 25 February 2014 15:52, Casey Ransberger <[hidden email]> 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

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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Recedite, plebes! Gero rem imperialem! = Stand aside plebians! I am on imperial business.

Below

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)

On 26.02.2014, at 21:39, tim Rowledge <[hidden email]> 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 <[hidden email]> wrote:

>
> On 26.02.2014, at 21:39, tim Rowledge <[hidden email]> 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; [hidden email]; 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 <[hidden email]> wrote:
As do I.
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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
An algorithm must be seen to be believed.

On 26.02.2014, at 23:40, tim Rowledge <[hidden email]> wrote:

>
> On 26-02-2014, at 2:36 PM, Tobias Pape <[hidden email]> 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 ;)

On 26 February 2014 14:19, tim Rowledge <[hidden email]> wrote:
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 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; [hidden email]; http://www.rowledge.org/tim
> An algorithm must be seen to be believed.