> From: Mats Nygren <nygren at sics.se>
>
> IMO, the present {}-construction in Squeak is not necessarily in the 
> spirit of Smalltalk, no receiver, no identifiable selector.

That was my first thought as well.

> It remains to explain which message it is and after having become
> bored with seeing value:-messages for a while I decided to try the idea 
> of identifying the invisible {}-message with the value:-series of  
messages.

Yes, having to have #value: or #perform: messages is just as  
uninformative as f(x), just a whole lot more to type.

> Since this was easy and is useful I am trying it out now. It also  
looks like
> functional application.
>
> What you are saying in the rest of your message is interesting and  
I will
> take a look at it if you implement it. As far as I can see it  
lacks the immediate
> and effortless implementability of the brace-message.

Yes, I didn't realize at first that you were just reusing the  
existing {}-Syntax (which doesn't really register as part of Squeak  
for me...).   That makes it a true "lazy-hack", which is cool.

> Some example uses:
> with appropriate definitions of valueWithArguments::
> "#at: == #value: for arrays"
> the rest are for guessing

?

> > [snip]
> > However, isn't that really just a special case?  Isn't the
> > Symbol/Message just a specific instance of the 'Valuable' protocol,   
> > that is, things that (should) respond to #value:* ?  So maybe,   
> > anything that responds to valuable protocol should be able to take   
> > that spot in a message expression.
>
> This will create another language than ST-80, it should be possible 
> to have that in the same image in a well designed environment.

Strictly speaking, yes, but not really.  Syntactically, it will look  
(largely) the same, unlike a major expansion into functional  
programming.  Also, semantically, ST-80 will be fully embedded in the  
new language, and probably by >90% of its uses.  The others will  
mostly be more convenient notation for stuff that could have been  
done in a more roundabout way ( #value:, #perform:).  At least at  
first.

> > The idea actually crept up on me in a different context, my old   
> > favorite the trampoline-based higher-order messages, and how to   
> > integrate them with the block mechanism, seeing how they cannot   
> > really replace blocks for all purposes.
>
> Can you give me some pointers to the trampoline stuff? I know there are 
> postings on this but I never found them in the archives.

There are some details below, do you want to see code?

> > So maybe one could write a block  [ :each | each doSomething ]   
> > simply as  [ doSomething ], and use it in the same place as a  
normal
> > message.
> >
> > 	myCollection do [ doSomething ].
>
> try
>
>   myCollection do {[ :each | each doSomething ]}

well, that is just as verbose as

	myCollection do: [ :each | each doSomething ].

One of the points of the trampoline-based stuff was having a more  
shorthand notation that is less focused on single objects.

	myCollection do doSomething.

is the equivalent expression with trampolines.  Another aspect is  
that you can vary any part of the message expression, without  
obscuring the original message expression, for example

	2 collect raisedTo:#( 1 2 3 4 5 6 7 8 ) each
or better
	2 collect raisedTo:( 1 to: 8) each

versus
	
	(1 to: 8) collect: [ :each | 2 raisedTo: each ]

will all yield powers of two.  And finally there's the part that  
gets difficult with the standard iteration methods:

	(1 to: 8) collect raisedTo: ( 1 to: 8 ) each

produces 1^1, 2^2, 3^3 etc.  This extends to any number of arguments  
and any mix of fixed or variable arguments, without any additional  
code.

> and implement value: appropriately for whatever do produces
>
> Or perhaps I misunderstood, is 'doSomething' a symbol or any code? 

Just a symbol.

> > Before everybody yells  bloody murder, I know that there are
> > problems with this, it is just an intermediate idea.
>
> intermediate idea's are great considering final ideas
>
> > [snip]
> > One major difficulty is dealing with keyword messages, although I   
> > haven't really put much effort into trying to find a solution.
>
> On important part of this is collecting several arguments, the
> {}-construction captures that.

Yes it does, and it may actually be a solution to the problem.   
However, I'd rather have keywords...

> Try combining it with Craig Latta's streaming machinery that is being 
> ported to Squeak.

Interestingly enough, the original Objective-C implementation is  
iterator/stream-based, although I admit to whimping out when I did  
the Smalltalk port.

> Think about how it will fit together with Dan Ingall's Fabrik.

Not sure.

> I will appreciate your comments on my next posting about functional 
> squeak, "more value (functional squeak)".

Will do, it looks interesting.

> As you probably know I want Squeak to be organized to make different 
> language variants such as yours easy to try out. By separating the 
> syntactic part of that from the semantic.

Yes, that sounds like a good idea.  For me, I want to keep the  
syntax as much as possible while being able to fine-tune semantics as  
necessary.  I really mean 'fine-tune' because that is often all  
that's needed and that way the system remains predictable.

Marcel