> From: Mats Nygren <nygren at sics.se>

> I meant in particular the new possibilities that arises. That will make 
> it possible to write in entirely different ways even within the same 
> syntax. In that sense it is a new game to play.

Yes definitely!  However, this is where Alan's warnings come into  
play:  you don't want to do have gratuitously non-obvious semantics  
happening.  I am fairly optimistic that this can be controlled,  
especially since you can already have unexpected things happening  
today.

> >> 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?
>
> I would like to see code, and also if you have some explanation of the 
> general ideas, probably others will have an interest in that. Perhaps 
> you have some old Squeak-list thread?

I just re-posted it in another reply.

[just a symbol]
> Then
> 	myCollection do: [ :each | each doSomething ].
> can be written
> 	myCollection do: #doSomething.

Ah, I was a little sloppy there myself:  what can follow is a  
complete message expression.  The message will be caught along with  
all its arguments, provided with a receiver and then used in normal  
#collect: iteration messages.  At least this is how it works in the  
code I've given.

The original Objective-C code actually uses iterators.  All the  
iterators are stepped through simultaneously, while non-iterators are  
kept constant during evaluation.  The assumption here is that you  
never want to use an iterator in an iterating context without  
iterating over it.  With a collection, this is not always a valid  
assumption, which is why iterators are important in that context.  A  
Smalltalk solution would need to use Streams, but that also has the  
'discrimination' problem:  you couldn't assume that having a stream  
in there always means that you want to stream its contents  
automagically.

> which is ok to my standards. But it seems you can handle nested  
loops in
> elegant ways, I havn't really understood your framework yet.

Well, nesting *could* be handled, but isn't.  All the 'framework'  
really does is extend the concept of 'message send' a little:   
instead of being able to send a message to just a single receiver,  
you can send it to lots of receivers.

Because the operations are really very similar, the syntax is also  
very similar, sort of like writing many receivers on a mail message.   
This contrasts with the current way, where the change from a single  
receiver to many receivers means you suddenly leave messaging  
altogether and have to resort to anonymous functions.  Wowzers!

There is actually an interesting scripting language, FScript, which  
extends this entire iteration concept and takes it off in the  
direction of APL (see www.fscript.org).  However, I am not sure  
wether APL is a good generalization to make.

> To me it seems like you are currying functions, in particular the
> Collection-traversals. If you are familiar with the
> "lambda-calculus/combinatory logic"-terminology it would be  
interesting to
> read
> a description of this in such terms.

It does have some aspects of currying (see the code-comments), but  
traditional currying is a little difficult with Smalltalk as it is:   
how to drop keywords?  Of course, one way would be to view a  
multi-keyword message as a sequence of single keyword messages slowly  
constructing a message-objects with key/value arguments.  However, I  
think that direction has been explored quite a bit already.

> Is it possible to have your way of doing things alongside the  
established way
> controlled by metaobjects, as in CLOS? (By making a specical  
generic function
> class
> with its own way of application)

I actually use the standard way (at least now).  However, I am still  
lookin at how to extend these ideas.  One important requirement for  
me is that the result should 'fit' in with the concept of  
communicating objects, or at least something similarily concrete.   
What I don't want to do is a plain 'import'  of concepts from FP,  
although I do want the capabilities.

> Anyhow my guess is you are doing things similar to ideas I have been 
> experimenting with outside of Squeak. After my vacation it should  
be fun
> to get into this.

Great!

Marcel