Getting double semi as sequencer harvested.

Hi Vassili

I started the following report on mantis and uploaded
the second of your code offerings. See:


http://bugs.squeak.org/view.php?id=6649
0006649: [RFE] [Code] Request ";;" (double semi) be
added to language as a "then" sequencer.


To complete the report to the havestable stage
following things IMO need to happen.

The code has to be slimmed down to just the
double-semi.

The token may want to be renamed way from pipe to
something closer to the "and then..." or "and next..."
meaning.

There should be at least some simple tests written to
prove double semi works as intended.

It would be great if you looked in on the report and
wonderful if you followed thru with your initial
effort and helped get this ready for harvesting.

I started to send you a "reminder" directly from the
report but I wasn't absolutely sure that "vassili" and
you were one and the same.

Cheers.

Yours in curiosity and service, --Jerome Peace









       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

On 9/2/07, Jerome Peace <[hidden email]> wrote:
> Hi Vassili
>
> It would be great if you looked in on the report and
> wonderful if you followed thru with your initial
> effort and helped get this ready for harvesting.

Harvesting?  To where?  This doesn't need to be in the main image imo.
 It's still in experimental stage.  Let's see some concrete proof that
it helps first.

> I strongly disagree that this should be in the main image.
> This would encourage code that is not ANSI compliant, and I'm
> quite happy with my parenthesis.
>
> Michael.

Are you saying you don't ever want to see the Smalltalk language grow beyond
its current state?  We have a special operator for cascades to get at the
previous receiver, seems only natural to want one for the opposite to get at
the previous result.  Personally, I can live with Bert's asPipe solution,
however, I think this is a nice language addition and I'd like to see it
added in some form.

Ramon Leon
http://onsmalltalk.com

At least I hope we don't use ;; .  That looks like a typo and it will
be easy to do accidentally as well imo.

On 9/3/07, Ramon Leon <[hidden email]> wrote:

2007/9/3, Ramon Leon <[hidden email]>:
The road to hell is paved with good intentions.

Cheers
Philippe

> Ramon Leon
> http://onsmalltalk.com
>
>
>

As is the road to heaven, were I to believe in such things.

Ramon Leon
http://onsmalltalk.com

2007/9/3, Ramon Leon <[hidden email]>:
And the road to heaven is more syntax? Java and C# are already taking
this way and C++ is where it leads. I'm not sure that's where we want
Squeak to be heading.

Cheers
Philippe

> Ramon Leon
> http://onsmalltalk.com
>
>
>

On Sun, 02 Sep 2007 22:14:26 -0700, Philippe Marschall  
<[hidden email]> wrote:

> And the road to heaven is more syntax? Java and C# are already taking
> this way and C++ is where it leads. I'm not sure that's where we want
> Squeak to be heading.

And C++ just keeps gettin' bigger, too.

Claims were made that pipes could reduce code size by a factor of 10 while  
increasing clarity. If true, it's certainly worthy. Even by 2 would be  
hard to argue with. One thing about traits is that you can see how the  
code is cleaner (and even then, there's still reistance).

It's reasonable to ask for some evidence.

I agree, by the way, that ";;" looks like a typo, and it's a little  
disturbing when coming from another language since multiple semi-colons  
are usually semantically meaningless.

>>>>> "Ramon" == Ramon Leon <[hidden email]> writes:

Ramon> Are you saying you don't ever want to see the Smalltalk language grow beyond
Ramon> its current state?

Yes.

--
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!

Blake wrote:
> Claims were made that pipes could reduce code size by a factor of 10
> while increasing clarity. If true, it's certainly worthy. Even by 2
> would be hard to argue with. One thing about traits is that you can see
> how the code is cleaner (and even then, there's still resistance).

Do you have an actual example of how the code is cleaner or are you
simply repeating what other people tell you? I've been looking for good
examples for traits for a couple of years now but it seems that when
things go beyond the toy examples presented in the papers traits create
more complexity than they help to address.

> It's reasonable to ask for some evidence.

Indeed. Correcting mistakes is reasonable too, but both usually don't
happen.

Cheers,
   - Andreas

On Sep 3, 2007, at 0:19 , Andreas Raab wrote:


Supposedly the "pipe syntax" is for helping to deal with to many  
parens, right? So I tried this:

        | n found |
        found := OrderedCollection new.
        'Decompiling all classes...'
                displayProgressAt: Sensor cursorPoint
                from: 0
                to: CompiledMethod instanceCount
                during: [:bar |
                        n := 0.
                        SystemNavigation default allBehaviorsDo: [:cls |
                                cls selectorsDo: [:selector |
                                        (n := n + 1) \\ 100 = 0
                                                ifTrue: [bar value: n].
                                        ((cls decompile: selector) decompileString includesSubString:  
'(((')
                                                ifTrue: [Transcript cr; show: '***' , cls name , ' ' , selector.
                                                        found add: cls name , ' ' , selector]]]].
        SystemNavigation default
                browseMessageList: found asSortedCollection
                name: 'Triple Parens' autoSelect: '((('


In my 3.8-based image this matched 96 of 50000 methods. These are  
mostly bit arithmetic and conditionals, and a few occurrences of  
multiple select:/collect:/do:'s. But honestly, none of them, even the  
latter, would benefit (IMHO) from the pipe operator.

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).

- Bert -

On Mon, 03 Sep 2007 00:41:20 -0700, Bert Freudenberg  
<[hidden email]> wrote:

> In my 3.8-based image this matched 96 of 50000 methods. These are
> mostly bit arithmetic and conditionals, and a few occurrences of
> multiple select:/collect:/do:'s. But honestly, none of them, even the
> latter, would benefit (IMHO) from the pipe operator.

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. But I  
haven't seen anything yet.

> 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.

It is tough to beat a good simplicity. (Make everything as simple as is  
possible, but not simpler?)

> 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).

Neat.

On Mon, 03 Sep 2007 00:19:29 -0700, Andreas Raab <[hidden email]>  
wrote:

> Blake wrote:
>
> Do you have an actual example of how the code is cleaner or are you  
> simply repeating what other people tell you? I've been looking for good  
> examples for traits for a couple of years now but it seems that when  
> things go beyond the toy examples presented in the papers traits create  
> more complexity than they help to address.

I know you feel that way and I'm not in a position to make a complete  
argument one way or the other yet. But I =would= maintain that the removal  
of duplicate code and the segregation of responsibilities into meaningful  
compartments results in a set of collection classes that is cleaner and  
actually easier to apprehend.

Maybe I'll come out of my current experiments with the same opinion you  
have, I don't know. But the competing ideas I've tried have not done  
anything for me. And I'll share my results but of course I can't guarantee  
you won't think they're toy.

>> It's reasonable to ask for some evidence.
>
> Indeed. Correcting mistakes is reasonable too, but both usually don't  
> happen.

I'm not sure if this is a cryptic reference to believing that traits is a  
mistake and should be removed but if so, it would seem to be easy to undo  
relative to the scope of the issues being tackled.

Ramon Leon wrote:
>> I strongly disagree that this should be in the main image.
>> This would encourage code that is not ANSI compliant, and I'm
>> quite happy with my parenthesis.
>>
>> Michael.
>
> Are you saying you don't ever want to see the Smalltalk language grow beyond
> its current state?

The language can grow and evolve, but just please keep the evolution out
of the official Squeak image. It needs cleaning up and shrinking to the
common essentials that all the forks of Squeak use rather than more
evolutionary appendages.

Michael.

Blake wrote:
Yes, abstractly speaking that is so. However, that removal of duplicate
code doesn't come for free - it comes with the cost of extra entities
that a user needs to understand and which makes for more complexity that
one has to deal with. It comes with multiple inheritance hierarchies
that users need to understand which makes for more complexity. It comes
with required, provided, renamed, and excluded methods that a user needs
to keep in mind and makes for more complexity.

If it were *only* the removal of duplicate code, this would be hard to
argue with. But it isn't; traits make a very complex set of tradeoffs in
the hope to do more good than bad. However, practical examples seem to
indicate that the net result is more complexity rather than less. See
for example:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119295.html

> Maybe I'll come out of my current experiments with the same opinion you
> have, I don't know. But the competing ideas I've tried have not done
> anything for me. And I'll share my results but of course I can't
> guarantee you won't think they're toy.

I'm looking forward to it. In my experience the best way to deal with
complexity is to factor it into objects, not traits, and use trivial
delegation methods where necessary.

>>> It's reasonable to ask for some evidence.
>>
>> Indeed. Correcting mistakes is reasonable too, but both usually don't
>> happen.
>
> I'm not sure if this is a cryptic reference to believing that traits is
> a mistake and should be removed but if so, it would seem to be easy to
> undo relative to the scope of the issues being tackled.

It is a cryptic reference to people who without having even looked at
traits repeat all the "benefits" that they have been told (which doesn't
just apply to you). It's quite sad actually. If more people would be
actually looking at traits we might even have an interesting discussion.
Without it, you get these "traits are great, of course I have never used
them, but I'm sure with them everything is better" arguments.

Cheers,
   - Andreas

On Mon, 03 Sep 2007 02:22:17 -0700, Andreas Raab <[hidden email]>  
wrote:

[a whole bunch of stuff]

I actually penned a more detailed reply but I don't think it would, for  
the most part, bear fruit. I agree with a lot of what you said, and  
disagree with some other parts. My only purpose in bringing up traits is  
that the collection example (while "toy") at least makes a persuasive  
arguments, especially when compared with nothing (pipes-enhanced code).

This, however, got me thinking:

> I'm looking forward to it. In my experience the best way to deal with  
> complexity is to factor it into objects, not traits, and use trivial  
> delegation methods where necessary.

...since (as a long-time Delphi programmer) I'm working backwards from  
that viewpoint. Delegation has some great applicability and it can also  
enable some terrible design. But if delegation really can serve the same  
purpose as traits, it should be possible to refactor the collections class  
using delegation and receive most of the benefits without most of the  
complexity. Yes?

        ===Blake===

My point of view is that traits helping produce more clear protocol
and avoid #shouldNotImplement stubs. And with delegation you tend to
have heavier protocols.
But i think that this mainly depends on developer. Both approaches,
when misused can lead to horrible results :)

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.


On 03/09/07, Blake <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.

For those who care, my opinions on this subject:

1) I once proposed the idea of pipes (I don't like the name pipe and didn't use it)
    so I am obviously biased in favor of pipes and am confident that,
    once implemented, pipes will gain popular acceptance. 
    Nevertheless, I think it would be irresponsible to just add pipes to Squeak. 
    I suggest, instead, that the next release of Squeak be paired with
    an experimental version containing pipes that people can play with.
    The experimental version release will be delayed by the amount of time
     needed to implement the pipe operator and use it in a few conspicuous places.

2)  I am not worried about Squeak becoming too different
     from other versions of Smalltalk.
     If the pipe operator is as successful as I expect it to be then the other versions
     of Smalltalk will eventually adopt it as well.  Then this issue will go away.
     In fact, perhaps this discussion should be occurring with
     the entire Smalltalk community.

3) I am against the use of  ;;  as the pipe operator.
    It will have all the same problems as  = vs. == in  C.
    ;  and ;;  are similar enough to be mistyped and it will be difficult to
    find the problem once the typo is made.
    I much prefer  ::  or even  :-:.
    Beginners may have problems remembering which is which between ;  and ;;.

4) I think we need to review the current code in Squeak to find examples
    where the pipe operator can be used. 
    One should note that this is not simply a matter of finding places
    where lots of parentheses are used. 
    Often, instead, the coder has avoided using excessing parentheses
    by introducing temporary variables.
    Thus, there may be places in the code where:

     | a b c ... |
    ...
    a := expression1.
    b := a expression2.
    c := b expression3

can be replaced by:

    | c ...  |
   ...
   c :=  expression1 
      :-:  expression2
      :-:  expression3.

Finding all the places where such code can be cleaned up will not be easy and have
to be done gradually once the pipe operator has been accepted.

5) I don't like the  'then' or  'and_then'  name for the pipe operator. 
    To me these names sound more appropriate for the cascade operator.
    How about   'ForwardResult' or 'ForwardResultTo' or just 'ForwardTo'
    as the name for the operator.  Too bad we can't use 'Cascade'.

Ralph Boland

On 9/3/07, Blake <[hidden email]> wrote:
> On Sun, 02 Sep 2007 22:14:26 -0700, Philippe Marschall
> <[hidden email]> wrote:
>
> Claims were made that pipes could reduce code size by a factor of 10 while
> increasing clarity. If true, it's certainly worthy. Even by 2 would be
> hard to argue with. One thing about traits is that you can see how the
> code is cleaner (and even then, there's still reistance).

There have been many false and downright nonsensical claims made in
this thread.  A factor of 10 would be one of those.  A factor of 2 is
pretty unlikely.  In every place you find lots of parens then it will
be turning each pair into one character.  So that sounds more like
maybe a 2% reduction if there are lots of parens.  If that was all
there was to it.  But it isn't.  With this he wants to remove all
kinds of methods like:  #add:after: so those turn into multiple
statements probably more then doubling the size.  So the code size
will actually get larger on the whole with this change.  Granted I
haven't ran any tests to verify this, but proof would seem out of
place in this thread. :)