Can i has underscores? :)

Maybe Andreas' solution is too confusing. However
we all have been warned by Ian, see [1] ;)

While I appreciate that it is now possible in the trunk image
(since I originally brought up the issue) I still
would vote for fully allowing underscores without any
preference.

We all know about the fear of "ugly code" but one
could write ugly code without it. I would vote for
the general freedom to use it.

Couldnt we follow the other Smalltalks who seem to
have no problem with it and the good old rule to
keep it simple.

Bye
T.


[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146567.html


--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

2010/4/14 Torsten Bergmann <[hidden email]>:
> Couldnt we follow the other Smalltalks who seem to
> have no problem with it and the good old rule to
> keep it simple.

Don't we have different priorities as a community than other Smalltalk
dialects? My point is that we have limited development resources and
this very specific feature does not add anything other than a
preference in style. The reward is too little. I vote for a better
prioritizing of features to be supported. ;)

Ian.
--
http://mecenia.blogspot.com/

+1


Sam S. Adams, IBM Distinguished Engineer, IBM Research
Mobile: 919-696-6064, email: [hidden email]
Asst: Kenndra K. Quiles. (732) 926-2292 Fax: (732) 926-2455, email: [hidden email]
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>


[hidden email] wrote on 04/14/2010 09:15:38 AM:

> Ian Trudel <[hidden email]>
> Sent by: [hidden email]
>
> 04/14/2010 09:15 AM
>
> Please respond to
> The general-purpose Squeak developers list <squeak-
> [hidden email]>
>
> To
>
> The general-purpose Squeak developers list <squeak-
> [hidden email]>
>
> cc
>
> Subject
>
> Re: [squeak-dev] Can i has underscores? :)
>
> 2010/4/14 Torsten Bergmann <[hidden email]>:
> > Couldnt we follow the other Smalltalks who seem to
> > have no problem with it and the good old rule to
> > keep it simple.
>
> Don't we have different priorities as a community than other Smalltalk
> dialects? My point is that we have limited development resources and
> this very specific feature does not add anything other than a
> preference in style. The reward is too little. I vote for a better
> prioritizing of features to be supported. ;)
>
> Ian.
> --
> http://mecenia.blogspot.com/
>

On 14.04.2010, at 15:15, Ian Trudel wrote:
Everyone has different priorities here. But if someone chooses to put time into a certain feature they need, and it is acceptable to the rest, why resist it?

The basic consensus was to support underscores, but to not use them in official packages (unless there were very compelling reasons to do so, which yet have to be demonstrated).

- Bert -

This issue has been discussed very comprehensively not long ago.
Andreas's solution was considered the best by the majority of the
intervening people.

Stef

It was never a question for me, should Squeak change syntax to use
underscores in names instead of
assignment or not.
It was good to see back-arrow in text
a ← b
in older images.
But its completely ugly and inacceptable for me to see things like this:
a _ b.
This doesn't fits with my aestetic tastes. Much less, comparing seeing
underscores in identifiers!

For those who prefer to use a single character for assignment, i say:
NO PROBLEM.
We have a unicode , so its a mere question of picking a right unicode
character and use it in source and parser.
http://www.alanwood.net/unicode/arrows.html
← U+2190

And we can modify editors to use a special keystroke for entering it:
ctrl-minus
or
alt-minus
but not shift-minus which stands for underscore.

For me, it is obvious and explicit: backwards arrow is not an
underscore and never was.
And, all who saying 'lets keep underscores' is ones who want to keep
our smalltalk dialect balkanized from the rest of the world.


On 14 April 2010 16:02, Torsten Bergmann <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

On 4/14/2010 7:47 AM, Igor Stasenko wrote:
> And, all who saying 'lets keep underscores' is ones who want to keep
> our smalltalk dialect balkanized from the rest of the world.

Sorry, but that's complete BS. The main motivation to keep things as is
was backwards compatibility. No solution has been brought forward to
address the issue of how to deal with existing code that uses underscore
assignment. As long as nobody is offering a solution to this problem,
I'm not willing to give up underscore assignments. If you can't even
load the code that's been written for 4.0 into 4.1 something's
*seriously* wrong with your priorities.

Not being able to load code *written for Squeak* into Squeak, hurts us a
*lot* more than not being able to load code into Squeak that wasn't
written for it.

Cheers,
   - Andreas

On 14 April 2010 18:32, Andreas Raab <[hidden email]> wrote:
> On 4/14/2010 7:47 AM, Igor Stasenko wrote:
>>
>> And, all who saying 'lets keep underscores' is ones who want to keep
>> our smalltalk dialect balkanized from the rest of the world.
>
> Sorry, but that's complete BS. The main motivation to keep things as is was
> backwards compatibility.

I know. But i didn't wanted to start ranting about it at all. :) My
humble question was
about the status, and question about is there a way to use underscores or not.
Look: loading code is an import procedure, and as any import, it could
perform any number of conversion steps
starting from source and ending with a ready-to-use material,
including treating underscores as assignment or something else.
Let me repeat: this is about conversion from external source, not
about internal representation of code in system.

It is surprising for me, to see that people know for a long that
things like .sources and .changes files are not real text files
and should not be treated in such way. So, it was never a big problem
in keeping a good and solid fence between squeak's internal world and
rest of the world. And why its going to be a problem of keeping such a
fence between old-time squeak and new one? This is a very same thing.

It could be kept very simple by having two different procedures:
 - import old code
 - import new code

or even keep a single import , which defaults to old syntax,
but for each fileout from a new system, in all .st and .cs files add a
one-liner:

SourceCode usingUnderscoreForNames!

A file-in tools then reset this flag before any file-in attempt:
SourceCode resetUnderscoreSetting

so, you can keep loading old code, as well as can load a new code
without a problem.
That's it. No preferences, no guessing about source file format
whether it comes from ages or just 1 day old. Just an explicit
statement.

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

> Not being able to load code *written for Squeak* into Squeak, hurts us a
> *lot* more than not being able to load code into Squeak that wasn't
> written for it.

I could not agree more.

Stef

2010/4/14 Stéphane Rollandin <[hidden email]>:
>> Not being able to load code *written for Squeak* into Squeak, hurts us a
>> *lot* more than not being able to load code into Squeak that wasn't
>> written for it.
>
> I could not agree more.
>
I am agree too. Completely.

Now pick any well-known software which evolved over a 10 or more years, and
tell me, how often they changing a document formats from one to another version,
while keep handling old files just as well as a new ones.
Is this a something impossible for us to do the same?
Why if its not a problem for rest of the world of importing an old-format data,
for us this seems like an impenetrable barrier?

> Stef
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 4/14/2010 8:57 AM, Igor Stasenko wrote:
Yes "we could", "we might perhaps" or "we ought to consider". So where
is that code you speak of? I have been asking for it during the ealier
discussions. The only thing I got back was hand-waiving.

Cheers,
   - Andreas

On 14 April 2010 19:13, Andreas Raab <[hidden email]> wrote:
Completely correct statement.
Now think, who will write this code, knowing that some of hand-wavers
turn into a 'only over my dead body'
after you give them a working solution. So, why wasting time on
something which will never be accepted?
I know for myself, how many of my ideas was rejected. And how many
things which i implemented never adopted
in Squeak.
So, i found that its better to keep discussing these issues over and
over again, up to the point where majority accepting the proposal,
only then its worth spending time implementing it.
A "do it, and we'll see " is not motivating enough for me to do it.

> Cheers,
>  - Andreas
>


--
Best regards,
Igor Stasenko AKA sig.

> Why if its not a problem for rest of the world of importing an old-format data,
> for us this seems like an impenetrable barrier?

because it's not data, it's syntax.

Stef

2010/4/14 Stéphane Rollandin <[hidden email]>:
>> Why if its not a problem for rest of the world of importing an old-format
>> data,
>> for us this seems like an impenetrable barrier?
>
> because it's not data, it's syntax.
>
Wrong. Computer can't make a difference between one sequence of bytes
and another one.
It is we, humans, who making a difference and instructing computer to
process one data differently than another.

As for proof experiment: open an .image file in text editor and tell
me, where is all of so-called syntax gone.

> Stef
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 4/14/2010 9:26 AM, Igor Stasenko wrote:
It's a measure of your interest in moving this issue forward. If you
don't care enough to write the conversion code, why would anyone else?
Remember this is an "scratch your own itch" community; you can't expect
others to do things for you if you're not willing to do them yourself.

> I know for myself, how many of my ideas was rejected. And how many
> things which i implemented never adopted in Squeak.

I don't actually recall very many. Definitely fewer than the ideas I've
posted and that never got implemented or adopted :-) If you want *all*
of your own ideas adopted you'll have to write your own system. This is
a community and we make community decisions, meaning that not all of
your (or mine, or anyone else's) ideas will get adopted.

> So, i found that its better to keep discussing these issues over and
> over again, up to the point where majority accepting the proposal,
> only then its worth spending time implementing it.

I think that in this case this may be a flawed approach. We know people
feel differently about this issue. I think we can get agreement that the
core should be "underscore neutral" i.e., not requiring a particular
underscore interpretation (neither assignment, nor selector etc).

This leaves the question of what the default interpretation for a
shipping release should be. And from my point of view, that decision
depends *purely* on the compatibility issue. We simply can't afford not
to be able to file in our own code.

There are various other simple things that could be done to soothe the
underscore proponents, for example rendering := as <- via Shout instead
of pretty print *which destroys method formatting). But these
discussions are kinda pointless as long as we have the gaping
compatibility hole.

Cheers,
   - Andreas

well, if it so, why are people commonly speaking of Lisp as the only
language where code format is the same as data format ? which allows
macros, backquoting, etc. anyway I don't want to argue on this point, as
the distinction is very clear to me, so if we don't agree let it be so.
I believe I have said enough about the underscore issue in Squeak; I
have nothing more to add about this.

best,

Stef

On 14 April 2010 20:09, Andreas Raab <[hidden email]> wrote: Of course, i don't expect that someone would do anything i'd like to
be implemented.
I was speaking about, that when you doing something for community -
you expecting that it will be used.
Otherwise, you doing it for youself, and really don't care what others
thinking about it.
That's why i won't run implementing something before i know for sure
that its useful for people.
I have many other things, to be fun with, which i never ever think to
propose here and doing in my corner for myself.

>> I know for myself, how many of my ideas was rejected. And how many
>> things which i implemented never adopted in Squeak.
>
> I don't actually recall very many. Definitely fewer than the ideas I've
> posted and that never got implemented or adopted :-) If you want *all* of
> your own ideas adopted you'll have to write your own system. This is a
> community and we make community decisions, meaning that not all of your (or
> mine, or anyone else's) ideas will get adopted.
>
Yes, i accepting that. But sometimes...
AFAIK, there are a tools existing for autoconverting underscore
assignments to := during filein.
Also i seen a small class which runs through existing source and
replacing all _ with := . Some of those tools are existing for years
by now.
So, what you are talking about? What compatibility problem? Is it a
very hard problem to run special scripts
while loading older code? I don't think so. So, sorry, i can't accept
that compatibility is a major issue here.

So, if its not a technical nor compatibility issue, then what is left?
What is left, is unwillingless of people to accept these changes for
the good of it.
And it is clear to me.

> There are various other simple things that could be done to soothe the
> underscore proponents, for example rendering := as <- via Shout instead of
> pretty print *which destroys method formatting). But these discussions are
> kinda pointless as long as we have the gaping compatibility hole.
>
No. It is wrong. Please, lets not take that route. Replacing a
character glyph representation is a bad idea.
If source code is text, then i expect it to be seen equally in any
text editor, regardless if editor knows
anything about smalltalk syntax or not. If you want to change the
visual representation of something in text, change the text,
don't hack the fonts or disguise one characters by another.
This is my personal opinion.

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

2010/4/14 Stéphane Rollandin <[hidden email]>:
Syntax is a tool for humans to let computer know what you want from it.
If you refusing to change the syntax because of various technical issues,
this means that you making yourself to be the servant of computer, to
please its expectations,
instead of making a computer to serve for you.

Before you start arguing why keeping old syntax rules better than a new ones,
if we leave all technical issues aside, i see a following benefits:
 - better interoperability with other languages (most modern languages
using underscores in identifiers)
 - better visual appearance of source code (seeing a := b is a way
better than seeing a _ b )

what benefits for keeping old syntax? I can't find any important one. And you?

> best,
>
> Stef
>

--
Best regards,
Igor Stasenko AKA sig.

Hi Igor,

So, what you want is:

Igor Stasenko wrote:
> ... i see a following benefits:
>  - better interoperability with other languages (most modern languages
> using underscores in identifiers)
>  

You already have that, just turn on the preference. There are a few
issues left, today I sent some fixes for those, in a message that was
ignored.

>  - better visual appearance of source code (seeing a := b is a way
> better than seeing a _ b )
>  

You always had that.

So, what is missing? The import filter to convert existing code to suit
your taste; the one you're not programming because it is not that
important for you? Something else?

Cheers,
Juan Vuletich

> what benefits for keeping old syntax?

backward compatibility; I have around 100000 lines of code to care for...

Stef