[Nice comments about trampolines]  Thanks ! (blush)

> You have to be careful rushing into this kind of thing, partly  
because of the
> subtlety aspect ("obfuscation", as Bob Jarvis puts it).

Definitely!  The confusion aspect was very much on my mind, and still is.

> Also if you get an error
> in a trampoline, things may have gone far beyond what the user had  
in mind -- as, eg,
> if you misspell a collection selector, and it turns around and  
tries to send it to
> one of its elements.

As they say, this turns out not to be the case :-)  The trampoline  
actually always forwards *all* messages sent to it, so trampolines  
have to be explicitly requested.  There is no logic of the type "if  
the message is not understood, then send it to the elements", because  
I agree that this has way too much potential for confusion (I am not  
good at precision syntax, as amply demonstrated by my posts, so I  
would be the first person confused)

So, the way to multiply an array by 2 using standard trampoline-like  
messaging would be

	#(1 2 3 4 5) collect * 2.

That makes it a bit less readable/convenient than the array  
processing code currently in the image, but makes for it for a simple  
additive syntax.  In my original Objective-C implementation, that  
was actually a shorthand for

	#(1 2 3 4 5) each collect * 2.

where "each" returns an iterator.  This also explains how collection  
arguments work:

	2 collect * #(1 2 3 4 5) each.
or even
	#(1 2 3 4) collect * #(4 5 6 7) each.

I think it looks quite strange when used with numerical operators,  
so the current specialized/optimized variants probably make sense to  
keep.

>  I think there is a "sweet spot" here but, as with some of our
> other pending projects, I think we need some careful review and  
experimentation
> before we pop it into the mainline release.

Sure!

Marcel