Getting double semi as sequencer harvested.

On 4-Sep-07, at 5:25 AM, Jon Hylands wrote:
And for those of us that find this 'shout' stuff to be an annoying,  
garish, pointless distraction?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Nice computers don't go down.

On 4-Sep-07, at 6:20 AM, Randal L. Schwartz wrote:

I'm of a similar opinion.

They're not pipes. It's a pointless bit of syntactic flummery (and  
not even saving any keystrokes!) that accesses no new semantics and  
actually looks *worse* than the thing it is supposed to improve. It  
is nothing whatsoever to do with functional programming.  Daft.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- One clown short of a circus.

On Tue, 4 Sep 2007 08:08:01 -0700, tim Rowledge <[hidden email]> wrote:

> And for those of us that find this 'shout' stuff to be an annoying,  
> garish, pointless distraction?

Personally, I don't use Shout, and I think this whole pipe thing is a silly
waste of time. I've been using Smalltalk continuously for 20 years now, and
I think the clean simple syntax is great. I also personally never use the
literal collection syntax {a.b.c}, because I prefer most of the baseline
non-UI Squeak that I write to be easily portable to other Smalltalks.

My point was, if we're going to add this to the base image, and many
developers use Shout, someone could enhance Shout to highlight ;; in a
different way, which would solve at least some of the problem of
distinguishing ;; from ; for that subset of developers.

Later,
Jon

ps - since I just turned 40 a couple days ago, that means I've been using
Smalltalk for half my life - pretty cool :-)

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

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

> >
> > If Shout is set up to highlight ;; in a different way than
> ; then it
> > would probably be clearer...
>
> And for those of us that find this 'shout' stuff to be an
> annoying, garish, pointless distraction?
>
> tim

Um, then don't load Shout.  Why complain about a potential feature in a
package you don't even like?

> > And for those of us that find this 'shout' stuff to be an annoying,
> > garish, pointless distraction?
>
> Personally, I don't use Shout, and I think this whole pipe
> thing is a silly waste of time. I've been using Smalltalk
> continuously for 20 years now, and I think the clean simple
> syntax is great.

So do I, but it isn't perfect and at times it can get a bit verbose when
doing conditionals or working with the collection hierarchy while trying to
avoid temporary variables.

> I also personally never use the literal
> collection syntax {a.b.c}, because I prefer most of the
> baseline non-UI Squeak that I write to be easily portable to
> other Smalltalks.

If one chooses to only write portable Smalltalk, what's the point in having
different distributions?  Squeak "IS" the experimental Smalltalk, the
proving ground for things that might later be accepted by those other
distributions.  If every Smalltalk had the same literal array syntax, I have
no doubt everyone would use them because they are clearly syntactically
better than the alternative.

> Later,
> Jon
>
> ps - since I just turned 40 a couple days ago, that means
> I've been using Smalltalk for half my life - pretty cool :-)

Congrats!

Ramon Leon
http://onsmalltalk.com

On 9/4/07, Igor Stasenko <[hidden email]> wrote:
One man's elegant is another man's dailywtf.com. :)  I don't like
double period for the same reason I don't like ;;.

On 9/4/07, Göran Krampe <[hidden email]> wrote:
>
> 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

Oops. :)  Then I change my vote to:   some variation with a > (e.g. =>
>= :> |>).

On Tue, 4 Sep 2007 08:46:18 -0700, "Ramon Leon" <[hidden email]>
wrote:

> If one chooses to only write portable Smalltalk, what's the point in having
> different distributions?  Squeak "IS" the experimental Smalltalk, the
> proving ground for things that might later be accepted by those other
> distributions.  If every Smalltalk had the same literal array syntax, I have
> no doubt everyone would use them because they are clearly syntactically
> better than the alternative.

Well, clearly I use Squeak for almost everything I do (at least
personally), but let's face it - most of the interesting stuff in Squeak is
not in what I consider the "baseline" classes - Collections, Numbers,
Streams, etc.

The really cool stuff in Squeak is in the graphics, and GUI, and Multimedia
support, and so on. It seems pretty obvious that none of this code is
portable to other Smalltalks.

I guess I should expand a bit here. Its not just because I like to write
quasi-portable code. I also have been doing this stuff for a long time, and
the literal syntax is a relatively new thing, and I just never saw enough
of an advantage to it, given the number of times I ever build collections
like that in real code.

I like things that are simple. One of the reasons I like Smalltalk so much
is because it is simple. The BNF chart for the language is incredibly
small. Any changes made to it should be carefully considered from a
cost-benefit analysis.

All this has been said before in the various threads on this subject.

Later,
Jon

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

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

I actually like Vassili's suggested :>, it's unused and implies the flow
nicely.

Ramon Leon
http://onsmalltalk.com

On 9/4/07, tim Rowledge <[hidden email]> wrote:
Lol.  I hope you never leave this list, such directness in our PR
times is quite refreshing. :)

But I think you might be looking at the OP's examples.  Vassili's blog
[1] had some better examples like:

somethings thingsAt: aKey :> includes: aThing :>
    ifTrue: [...]
    ifFalse [...]

Though for me it's not vastly better then:

((somethings thingsAt: aKey)
   includes: aThing)
     ifTrue: [...]
     ifFalse: [...]

But it does make you backtrack a bit to type it (well, at least
highlight the exp and type a ( ).

The obvious counter argument is: is this going to make it less obvious
when some code should be refactored ala "Smalltalk Best Practice
Patterns".

[1] http://blog.3plus4.org/2007/08/30/message-chains/.

> I like things that are simple. One of the reasons I like
> Smalltalk so much is because it is simple. The BNF chart for
> the language is incredibly small. Any changes made to it
> should be carefully considered from a cost-benefit analysis.
>
> All this has been said before in the various threads on this subject.
>
> Later,
> Jon

I agree, a syntax change shouldn't be made lightly, however, when even the
creator of the language says something's a good idea I think it's at least
worth exploring.  Not everything can be figured out by thinking alone, some
things take actual experiments and observation to see their effects.

This doesn't even need to be included in the base image for trial, it could
simply be an add on that includes the necessary patches for fixing syntax
aware packages like the Refactoring Browser and Shout.  

The problem of course is that syntax changes really do belong in the base
image and doing so is the only way to ensure critics will try it and find
any real problems, otherwise they're likely to ignore any add on package.

Someone earlier suggested there should be some sort of experimental branch
where things like this are tried out and only when successful, moved into
the main image.  That's not a bad idea.  I think many of the critics are
worried, and rightfully so, that once something makes it into the core it's
very hard to remove, especially if it's syntax.  

Of course, anyone can create such a distribution, but an official
experimental distribution would likely be far more useful and garner far
more testers if it were known as the official proving grounds.  Features
need a place where they can successfully fail without fear that you're stuck
with them.  Given such an environment, such features could prove themselves
and gain support through actual use rather than endless discussions.

Ramon Leon
http://onsmalltalk.com

We already have a way to display assignments as either _ or :=, right?

Excellent idea.




--
Hiren J.Thacker

On Sep 3, 2007, at 11:29 , e.spin wrote:

http://www.cs.ucla.edu/~awarth/ometa/

Also on SqueakMap (pkg OMeta)

This is part of VPRI's "Fundamental New Computer Technologies" research

        http://vpri.org/html/work/our_work.htm
        http://vpri.org/html/writings.htm

- Bert -

Hi,

Jon Hylands wrote:

 > I like things that are simple. One of the reasons I like Smalltalk
 > so much is because it is simple. The BNF chart for the language
 > is incredibly small. Any changes made to it should be carefully
 > considered from a cost-benefit analysis.

I agree with Jon that changes to the Smalltalk syntax need to be very
carefully considered. The perlification of Smalltalk has already begun
unnecessarily with the curly braces!

By perlification I mean the adding of syntax gone wild, especially when
it isn't needed or when it destroys the beauty of simplicity.

The piping capability looks interesting but lets seriously consider it's
impact upon the syntax and portability issues.


The Perlification of Smalltalk: Curly Braces and the Road to
PerlCrypticTalk.
Let's take the example of the addition of the curly braces to Squeak
Smalltalk. They provide a nice way to instantiate a collection of
objects very compactly. However, they unnecessarily added new syntax to
Squeak Smalltalk in my view. How?

The square brackets can do the same job with greater flexibility and
capabilities to boot! Blocks would simply have needed a small set of new
messages in their class and the virtual machine would just have needed
an enhancement for collecting as it evaluates. This wouldn't have added
any new syntax to Smalltalk thus avoiding a step towards Perl. Here are
some examples:

    "Same as using curly braces but importantly NO syntax changes needed!"
    list := [a. b. c] objects.

    "More flexible version that lets you collect the evaluated results
    into an arbitary collection of your own choosing."
    [a. b. c] addObjectsTo: aCollection.

    "Wow, even into a stream."
    [
        1 to: 1000 do: [:count | count random ]
    ] streamObjectsInto: aStreamOfRandomIntegers

Ok, the message names for the evaluation-results-collection protocol
might need some work but the principle is sound and much better than the
curly braces since it adds extra capability.


The Perification of Smalltalk: Piping Smalltalk into PerlCrypticTalk.
I fear that more time is needed to come up with a better piping
construct than the ones suggested although they may make sense. Maybe we
could inventory the suggestions made to date?

I fear the "perification" of Smalltalk syntax. Please keep it clean.

It might be wise towards ensuring portability of syntax changes that a
process be set up with all of those who create Smalltalk versions to
participate in some manner. Just wily nilly adding new syntax to just
one version of Smalltalk in an ad hoc manner without considering it's
wider impact can create a lot of confusion for people who use the
language. Isn't it confusing enough that we have 20+ versions of
Smalltalk out there? Now we have a version that is heading to become a
syntax mess like Perl.

I suggest a Smalltalk 2010 standard. Maybe that's too soon, but why not?

My two cents.

All the best,

Peter
[hidden email]

I agree.

Mark Volkmann wrote: Hi Mark,

The Smalltalk Blue Book has a copy of the original BNF as a visual
diagram at the back of the book, pages 737 through 741.

You can download a pdf copy form ACM.org here:
http://portal.acm.org/citation.cfm?id=273&coll=ACM&dl=ACM&CFID=28725035&CFTOKEN=39135639

Peter

could you tell us more?
Because I would like to see how it works.

Stef

agree.