Getting double semi as sequencer harvested.

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

This is my todo list but I cannot find them for that now.
I would love to see if we could do the same a with stream (Nile -  
damien is rethinking simplifying it) but for collections.

Would have replied "the syntax is so small it might appear empty"!

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Peter
William Lount
Sent: 04 September 2007 7:27 pm
To: Mark Volkmann
Cc: The general-purpose Squeak developers list
Subject: Re: Fear and loathing of the "perification" of Smalltalk


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&CFTO
KEN=39135639

Peter

Peter William Lount wrote: Hi Mark,

Cincom has a verbal bnf for their Smalltalk here:
http://www.google.ca/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fwww.cincomsmalltalk.com%2Fdocumentation%2Fvw7.5%2FAppDevGuide.pdf&ei=1KXdRpnQIIGGgAPppsCGAw&usg=AFQjCNFNd3fkAEkDTxneWjgZJL0MP2HwJg&sig2=O2xarVwQAjLHpryc48pbFg

Maybe James Robertson would be able to provide a copy of their BNF for
discussion purposes.

I think it's an excellent idea to collect all the current Smalltalk BNFs
so we can see the true horror or beauty of the situation... before we
make significant changes.

By the way I'm ALL for experimental changes but we need a means where
those changes become part of a "standard Smalltalk".

All the best,

Peter

>>>>> "Peter" == Peter William Lount <[hidden email]> writes:

Peter> The Perlification of Smalltalk: Curly Braces and the Road to PerlCrypticTalk.

I respectfully request that you not use Perl as a swear word in my presence.

:)

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

Randal L. Schwartz wrote: Hi,

Well it's not meant as a swear word exactly. It's meant as a comparison
between the simple Smalltalk syntax and the complex mess that is the
Perl syntax.  I was thinking of apologizing to the Perl community for
coining the phrase "perlification". Sorry about that but it's
descriptive beyond belief. Please accept my apology. I would have used
"APLification" but I didn't think that many would get it as well as the
Perl version.

Please see "The Simplicity and Power Comes from the Smalltalk Syntax"
linked here: http://smalltalk.org/articles/article_20040914_a1.html.

Cheers,

Peter

Vassili's best proposition is to use coma , which is consistent with
existing use of punctuation (period . and semicolon ;)

Unfortunately, it breaks compatibility with message selector #,
Rephrasing Tim, is it really worth?

Nicolas

Jason Johnson a écrit :

On Sep 4, 2007, at 11:53 , Peter William Lount wrote:

You could call it Smalltalk++ ;)

- Bert -

>>>>> "Peter" == Peter William Lount <[hidden email]> writes:

Peter> Well it's not meant as a swear word exactly. It's meant as a comparison
Peter> between the simple Smalltalk syntax and the complex mess that is the
Peter> Perl syntax.

I completely agree that Smalltalk's *syntax* is simple.

However, in any useful system, the "complexity" is a constant.  If you
simplify one thing, you complicate something else.  In Smalltalk, the
complexity shows up when you realize how much of the class libraries you have
to learn just to do anything simple.  In Perl, the complexity shows up when
you have to start learning the "contractions" (just as "can not" is replaced
by "can't", in Perl "readline ARGV" can be replaced by "<>").

It's all a matter of taste and area of application as to where you want the
complexity to show up.  You've shown your bias, and others would disagree, and
that's fine.  Just don't think your assessment is universal, and we can all
get along.

That's what I mean by "not using Perl as a swear word". It's not universally
loathed. :)

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

Merlyn,

Your last post was very, very useful to me as a beginner. It's lucid, and
useful, and by far the most valuable thing you've said -- for my learning
purposes -- since you turned up. I think I'll cut and paste that and read it
again tomorrow.

Chris

On 9/4/07, Randal L. Schwartz <[hidden email]> wrote:
> >>>>> "Peter" == Peter William Lount <[hidden email]> writes:
>
> I completely agree that Smalltalk's *syntax* is simple.
>
> However, in any useful system, the "complexity" is a constant.  If you
> simplify one thing, you complicate something else.  In Smalltalk, the
> complexity shows up when you realize how much of the class libraries you have
> to learn just to do anything simple.

It is true that sooner or later you have to do the complicated things.
 But in my personal experience, simpler syntax gives more options to
solve something elegantly and simply.  For example, in Smalltalk and
Lisp, two of the simplest languages there are (from a syntax
perspective) make it trivial to extend the language from within the
language.  You can build up the language to suit the problem you are
solving in a way that more complicated languages just can't.

It comes down to:  If the language is missing something, can I build
it, or do I have to wait for someone to add more syntax?

>In Perl, the complexity shows up when
> you have to start learning the "contractions" (just as "can not" is replaced
> by "can't", in Perl "readline ARGV" can be replaced by "<>").

It shows up a great deal with the complicated interactions with
variables and contexts as well.  If you ignore the constant version
problems, 90% of all the questions I see on the Perl support channel
where I work are of the nature of "how do a make an array of arrays?".
 When people ask this I generally point them to python. :)

On 04/09/07, Peter William Lount <[hidden email]> wrote:
> 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!

I understood "petrification" with the typo in the subject ;)

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

But  a. b. c  is a sequence that evaluates to the result of c. How can
the block see a and b without doing dirty tricks accessing its own
source code ?

IMHO curly braces are useful, they replace collection new add add add
in the same way cascade replaces receiver foo. receiver bar. receiver
baz. I'd accept message chains if they used the comma but it really
needs actual usage to proof it's useful.

Now I'd prefer discussions on compile-time expressions, how to extend
curlies to create arbitrary kinds of collections, and stuff like that.

--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

I think a much bigger win would be changing the scanner (if this
hasn't been done already) so we get the # back for extensions.  Then
we could easily add things like Lisp-style macros as Dolphin did ( ##(
"code") as I recall).

On 9/4/07, Damien Pollet <[hidden email]> wrote:

On 4-Sep-07, at 11:18 AM, Mark Volkmann wrote:


>
> Do you know where I could find a BNF chart for Smalltalk? I've  
> searched for grammars and came up empty.

http://wiki.squeak.org/squeak/409

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Gotta run, the cat's caught in the printer.

On Sep 4, 2007, at 12:42 , Damien Pollet wrote:

"[a. b. c]" is just a block defining a sequence of statements. The  
value depends on how you evaluate that block - sending #value only  
retains the last value, but you could as well define another  
evaluation strategy by sending another message.

One could even define new semantics instead of a sequence:

        [a. b. c] valueConcurrently

could mean to evaluate each statement concurrently.

- Bert -

On 04/09/07, Bert Freudenberg <[hidden email]> wrote:
But that involves VM and semantics changes that are far more heavier
than just adding syntactic sugar... To me a. b. c really means
"evaluate a then b then c and return the result of c". If you change
that then you have to
 - explain that period has different semantics depending on the context (*),
 - make it possible to define new evaluation semantics for blocs (why
two and not more)
 - fix the block optimisations, because now they are just sequences of
expressions with undefined a-priori semantics

etc etc etc

(*) just on this point I'd prefer to write something like
{[a]. [:x| x b]. [:x | x c]} valueAsChain

--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org

Damien Pollet wrote: Hi Damien,

Yes! "Petrification" is a nice meaning for "perlification" of Smalltalk.
The more syntax added to Smalltalk the more rigid and crusty it seems to me.

The curly braces require the same virtual machine statement evaluator
upgrade as the blocks version does, do it's not any more magic than the
curly braces are doing! The "objects" (or "values" if you prefer)
message simply calls an appropriate virtual machine primitive to collect
up the results of each statement. The normal block evaluator primitive
results the last result, the new one returns a collection of all the
results. The primitive for the block version would also optionally allow
you to provide your own collection of your own choosing to the primitive
- this provides much more flexibility than the curly braces can hope to
provide. Also the block version can of course be evaluated at any time
that you choose.

Curly Braces needlessly have added to the complexity of Smalltalk syntax
when block can easily do the same job.

Cheers,

Peter

Damien Pollet wrote:
> (*) just on this point I'd prefer to write something like
> {[a]. [:x| x b]. [:x | x c]} valueAsChain

Nah. I want to write:

   [a. b. c] piped.

SCNR,
   - Andreas

Damien Pollet wrote: No, the changes wouldn't be any more complex than what was done for
curly braces except for adding the parameterization of the passing in of
the collection that you want the results to flow into (including streams).
> To me a. b. c really means "evaluate a then b then c and return the result of c".
For normal default evaluation yes.

> If you change that then you have to
>  - explain that period has different semantics depending on the context (*),
>  
Nope. Period has exactly the same semantics. That doesn't change. It's
the evaluator that changes by collecting up all the results of
statements rather than just returning the last statement's result.

>  - make it possible to define new evaluation semantics for blocs (why
> two and not more)
>  
Yes, an excellent point. If you can think of another evaluator why not?
Yes, this should be parameterized, however this might have to happen at
the virtual machine level for performance reasons.

>  - fix the block optimisations, because now they are just sequences of
> expressions with undefined a-priori semantics
>  
Could you illuminate more on this, I'm not sure what you mean.

> etc etc etc
>
> (*) just on this point I'd prefer to write something like
> {[a]. [:x| x b]. [:x | x c]} valueAsChain
>
>  
What would this evaluate as and how would it evaluate? Would each
element of the collection be evaluated as a block and passed in the
value from the previous element? Otherwise where would the subsequent
block get their values?

Peter

On Sep 5, 2007, at 12:53 AM, Peter William Lount wrote:

> The curly braces require the same virtual machine statement  
> evaluator upgrade as the blocks version does, do it's not any more  
> magic than the curly braces are doing! The "objects" (or "values"  
> if you prefer) message simply calls an appropriate virtual machine  
> primitive to collect up the results of each statement.


No! the curly braces is not handle by the VM. Is translated by the  
compiler.

        Mth

Bert Freudenberg wrote: Hi Bert,

That's excellent Bert! With all the multicore chips out these days that
could be useful for the parallel programming paradigm (assuming that the
Smalltalk in question uses native threads to take advantage of those
cores). The tile64 chip has 64 cores and squeak will run on it with a
minimal port (linux, 32 bit, C compiler accepted).

Yes, "[a. b. c] value" returns one value, c, while "[a. b. c] values"
(or objects) returns three values in a collection. One could imagine
#valuesInArray, #valuesInOrderedCollection, #valuesInSet, #valuesIn:
aCollection, #valuesToStream:, etc...

Cheers,

Peter