Getting double semi as sequencer harvested.

On 9/3/07, Jason Johnson <[hidden email]> wrote:
> On 9/3/07, Blake <[hidden email]> wrote:
>
> So the code size
> will actually get larger on the whole with this change.

Ack, I thought "may" and typed "will". :)

I'm curious for your motivations here.  Do you like the language to be
simple, or do you just want Smalltalk to remain unpopular? ;)

On 9/3/07, Randal L. Schwartz <[hidden email]> wrote:

On 9/3/07, Blake <[hidden email]> wrote:
> On Mon, 03 Sep 2007 00:41:20 -0700, Bert Freudenberg
> <[hidden email]> wrote:
>
> I would be willing to concede the possibility that the pipe might benefit
> in ways not obvious from those 96 methods. I think the proposer suggested
> a shifting of paradigms, which I'm all about and for, baby--as long as we
> can switch back if the new paradigm isn't as good as the old one.

I'm afraid we don't have time to switch in the first place, much less
switch back.

Rather than base any counter arguments on absurd claims, just ignore the
absurd claims.  Vassili, as well as providing the initial implementation,
sums up the rational pro side quite nicely on his blog at
http://blog.3plus4.org/2007/08/30/message-chains/.  

The short of it being that logically, it seems like a decent idea, but only
time and some actual use will tell.

I image the same arguments were made when array literals were introduced,
but I'm glad they were because some things are done so often that they
should be supported syntactically.

Ramon Leon
http://onsmalltalk.com

> > Are you saying you don't ever want to see the
> > Smalltalk language grow beyond its current state?
>
> Yes.
>
> Randal L. Schwartz

That begs the question of why, since not even it's creator thinks the
language is perfect.  On this very subject, Alan himself said...

>> It's not a question of functionality, but of simple readability and
writeability.
>> This idea has come up a number of times in the past, and it is a very
>> reasonable one

And concluded with...

> Since Squeak is a completely open Smalltalk, and intended to be
> extended in major as well as minor ways, there is no reason whatsoever
> to prevent these ideas and more to be added (and I wish that people
> would take it upon themselves to extend the language).
>
> Cheers, Alan

Smalltalk is a beautiful language, but it isn't perfect, and it should
certainly continue to evolve beyond its current state.  To want to freeze
the language at a particular point in time and call it complete doesn't seem
to me to serve the spirit of Smalltalk.

Ramon Leon
http://onsmalltalk.com

Igor Stasenko wrote:
> In my asm-generator i found a good use of traits - like an extension
> mechanism which can be applied to any class to override some basic
> behavior. In my case, by adding a trait to some class,  i'm overriding
> methods which used for compiling instance side methods, so i can
> replace and/or extent parser or compiler features only for particular
> class(es)  without modifying parser/compiler globally.
> Also, i don't need to change inheritance chain in classes, where i
> adding traits.

Sounds interesting. Care to share it?

Cheers,
   - Andreas

Hi Bert,

Bert Freudenberg-2 wrote

[...]
I have the impression that Smalltalk has hit a "sweet spot" - there  
may be a few additions (compile-time expressions anyone?) but  
basically it is very succinct in expressing what the underlying  
system does, namely, sending messages to objects. Other languages  
needed to add a lot more over the years as they started out with a  
rather limited model, but if you start with a general model like  
Smalltalk did (which in turn was the result of many experiments) it  
is not necessary to add that much. Or, if you do it, it wouldn't be  
Smalltalk anymore (and that's in fact what Alan's group now is  
working on, there is a whole lot of experimenting with syntax going  
on using Meta).
[...]

What is this Meta thing you mentioned? Do you have any URLs, docs about it?
Thanks in advance
Bye
Enrico

+1 on this. A freezed system is a system that begins it's decay. We saw that
in nature also in the industry. That by no means imply that the system has
to evolve without discern.

        Cheers,

Sebastian Sastre

>>>>> "Jason" == Jason Johnson <[hidden email]> writes:

Jason> I'm curious for your motivations here.  Do you like the language to be
Jason> simple, or do you just want Smalltalk to remain unpopular? ;)

I just don't like version creep in languages.  Smalltalk has remained
relatively stable for nearly 3 decades.  Anything to disrupt that has got to
meet a pretty high standard for me personally.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

>>>>> "Sebastian" == Sebastian Sastre <[hidden email]> writes:

Sebastian> +1 on this. A freezed system is a system that begins it's decay. We
Sebastian> saw that in nature also in the industry.

That's an interesting straw man.  By that standard, Smalltalk would
have been *completely* dead 10 years ago.

Would you care to put facts behind your proposal?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Hi All,

Before we decide what to do,

Considering the usefulness and compatibility issues I'd vote against the
change.  

To answer questions of compatibility I'd vote for #asPipe.  I disagree that
#asPipe is a bad name, #asSequencer is not better.

The pipe operator ;; to me is still the best operator choice.  It has some
relation to the ; operator and would be easier to remember then other
proposed symbols.  I disagree that it would be easy to type wrong.  It seems
to stick out to me.  I disagree that it would be difficult to learn or teach
since it seems to be two sides of the same problem.  Also I disagree that
the two will get confused since determining which is which is easy enough to
do.  But if we can not agree to use ;; then I would again vote for using
#asPipe, which successfully answers all of these arguments.  

Again I would probably not use ;; at all.  I prefer parens or temps because
they make much more sense.  At least ;; seems tolerable and possibly
marginally useful.

So overall considering the usefulness I'd vote in the following order.

-1
asPipe
;;

So I vote no.  But if we must have the change and enough people agree then
I'd change my no vote to vote for #asPipe.  Again if enough people insist on
an operator then ;; gets my vote and I still vote against other suggested
symbols.

Happy Coding!!

Ron Teitelbaum  

decompileString
> includesSubString:
> '(((')
> ifTrue: [Transcript cr;
show: '***' ,
> cls name , ' ' , selector.
> found add: cls name
, ' ' ,

On 9/4/07, Randal L. Schwartz <[hidden email]> wrote:
> >>>>> "Jason" == Jason Johnson <[hidden email]> writes:
>
> I just don't like version creep in languages.  Smalltalk has remained
> relatively stable for nearly 3 decades.  Anything to disrupt that has got to
> meet a pretty high standard for me personally.

Fair enough.  I do agree with the sentiment that when things stop
advancing they start decaying, but in very simple/elegant languages
like Smalltalk or Lisp we can advance in the libraries without syntax
change.  Adding syntax can make things easier but it's not for free,
it's a cost of added complexity.

But if we must go with this thing then I would prefer the one in
Vassili's log.  That was the best argument and usage for this I have
seen yet, not to mention much more clear (to me) then the ;;.

Oh, but I like the :> better then :).  Maybe the best would be ->

On 04/09/07, Jason Johnson <[hidden email]> wrote:
Ohh.. there is many variants. like
|>
|=
|-
|)
||
|]
|.

But best, i think we can use double period.
..

a msg: param1 .. msg2: param2 .. msg: param3 .. fooz: buzz .. fee: buckz

Code looks nice and elegant :)

--
Best regards,
Igor Stasenko AKA sig.

On 03/09/07, Andreas Raab <[hidden email]> wrote:
It's still not finished.

Trait declaration:

Trait named: #AsmCompilerSupport
        uses: {}
        category: 'Asm-Generator'

And then in some class i simply changing class declaration like following:

Object subclass: #AsmCodeGenerator
        uses: AsmCompilerSupport
        instanceVariableNames: 'machine methods'
        classVariableNames: 'MethodLocations'
        poolDictionaries: ''
        category: 'Asm-Generator'


> Cheers,
>    - Andreas
>
>


--
Best regards,
Igor Stasenko AKA sig.

Hi!

> Oh, but I like the :> better then :).  Maybe the best would be ->

Disregarding the fact that I am against a grammar change of Smalltalk for
this:

Using "->" would be... eh, pretty daft! ;)

(Considering that we already use that particular token for something else)

regards, Göran

Hi fellow Squeakers!

First - I haven't followed this particular thread that much so consider me
fairly uneducated in the variations and nuisances of "pipes" as proposed.

But that has never stopped me from sharing my few cents :) :

Yes, Alan Kay wants Smalltalk to evolve - but he is IMHO not considering
the practical aspects that we as ONE Smalltalk implementation among others
(crossplatform issues) must do.

I personally also think that we should drive Smalltalk forward and not be
glued to the frozen ANSI standard. And including Traits was the first such
"move" in a long time, and even though we still don't know how it plays
out I think it was a healthy sign that we did it. :)

BUT... pipe? Come on - IMHO this is not even solving a *real* problem -
just giving us some syntactic sugar - and I generally dislike sugar in
languages. I think it will just create more problems than it will ever
"solve". I mean, what problem is it actually "solving"? Removing some
parenthesis? Is it really worth throwing away compatibility for that?

If we want to move Smalltalk forward I think we have lots of other much
more *interesting* bits to chew on like new notions of dealing with
concurrency or cleaning up base libraries (those covered by the std) or
whatever.

Having said that I also think that we could start some kind of simple way
for us to experiment without having to "choose" like this. One way is to
create an official continuously maintained "patch set" called
"Smalltalk-2000" or whatever that can be loaded on top of regular Squeak.
Maintained meaning that we "port" it onto each new version of Squeak. It
can contain several of these more drastical changes to Smalltalk and work
as a test bed.

This way people can try out these additions "in real life" and
Smalltalk-2000 could even build a strong following - and eventually we
could then consider bringing it into the slightly more conservative Squeak
line.

I think we also considered a similar approach to rewriting the Collection
classes - by making a new package called NewCollections that can be
installed without conflicts.

regards, Göran

On Mon, 03 Sep 2007 09:20:35 -0700, Jason Johnson  
<[hidden email]> wrote:

> I'm afraid we don't have time to switch in the first place, much less
> switch back.

Well, the beauty of Squeak is that you don't have to, right? Someone does,  
of course. But if someone does and other someones approve, and everyone is  
right, you get the benefits. Of course, if they're wrong, you probably  
have to suffer the consequences.

>> Any feature added to any system has to pass a basic test: If it adds  
>> complexity, is the benefit worth the cost? The more obscure or minor  
>> the benefit, the less complexity its worth. Sometimes this is referred  
>> to with the name “complexity budget”. A design should have a complexity  
>> budget to keep its overall complexity under control.<<[1]

Pipes add some complexity, probably minor, and unknown benefit. But I  
don't see there's a better--or any--way to discover what benefit that is  
short of trying it.


[1] Kevin Arnold's "Generics Considered Harmful":  
(http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html).  
Generics are all the rage right now but really validate Alan Kay's  
observation vis a vis static typing systems.

On Tue, 04 Sep 2007 00:24:54 -0700, Göran Krampe <[hidden email]> wrote:

> I think we also considered a similar approach to rewriting the Collection
> classes - by making a new package called NewCollections that can be
> installed without conflicts.

In the parlance of our times: +1

Of course, I have to think a truly revolutionary change isn't going to be  
at all painless.

On Mon, 3 Sep 2007 22:26:00 -0400, "Ron Teitelbaum" <[hidden email]>
wrote:

> The pipe operator ;; to me is still the best operator choice.  It has some
> relation to the ; operator and would be easier to remember then other
> proposed symbols.  I disagree that it would be easy to type wrong.

If Shout is set up to highlight ;; in a different way than ; then it would
probably be clearer...

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Raptor (Small Biped Velociraptor Robot)
           http://www.huv.com/blog

>>>>> "Göran" == Göran Krampe <[hidden email]> writes:

Göran> BUT... pipe? Come on - IMHO this is not even solving a *real* problem -
Göran> just giving us some syntactic sugar - and I generally dislike sugar in
Göran> languages. I think it will just create more problems than it will ever
Göran> "solve". I mean, what problem is it actually "solving"? Removing some
Göran> parenthesis? Is it really worth throwing away compatibility for that?

Hear Hear.  My point as well.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!