*  As Avi said, OOPAL's explicit message patterns can be handled at the
compiler level (and maybe even directly at run-time using Marcel Weiher's HOM-like
tricks). We might need something a little bit more sophisticated than the expansion to
collect: envisioned in Avi's message, though (for instance, the example for handling x @ 
foo:@ y by transforming it to x collect: [:eaX | y collect: [:eaY | eaX foo: eaY]] is not correct:
what we end up with is an outer product, not an element-wise application of the foo: 
method). Explicit message patterns can be handled by the compiler (or compiler + some 
run-time support) with very good performances.

* It is useful to handle *implicit* message patterns in the message sending routine itself. 
As far as performance is concerned, an important goal when implementing OOPAL's 
message patterns is to avoid any performance impact for the common, single message 
sending situation. In general, implementing support for implicit message pattern in the
message sending routine allows you to easily achieve this "zero cost" goal. 
However, the suggestion of implementing OOPAL's implicit message patterns trough DNU 
is interesting because, performance wise, I think it would also allows for a "zero cost in the 
classic case" implementation. But I'm not sure implementing implicit message pattern 
using DNU is possible (it might be possible, but, at first glance, it is not that obvious for 
me).     

* Syntax for message patterns: F-Script use the @ symbol for denoting message patterns, 
but this is not really adapted for Smalltalk because in Smalltalk @ can be used as selector 
(in F-Script @ can't be used as a selector). Using @ in Smalltalk would introduce an 
ambiguity. For instance in the expression x @ y, are we invoking the method @ on x or are 
we describing a message pattern. Adapting OOPAL to Squeak would probably require to 
replace the @ based syntax by something else (this would have the added benefit of 
making Andreas happy ;-) 

* Finally, note that message patterns are only half of the story. They become really, really 
powerful when you mix them with APL-like operations like compression etc. For instance, 
here is an example taken from the OOPAL paper (http://www.fscript.org/download/
OOPAL.pdf):

You have a collection P of objects representing pilots and you want
to get the name of those whose age is greater than 50. In Smalltalk you do:

(P select:[:aPilot| aPilot age > 50]) collect:[:aPilot| aPilot name].

In Smalltalk + OOPAL you do:

P name at: P age > 50

OOPAL's message patterns and APL-like array operations really go hand in hand.

Best,

Phil


--- In squeak at yahoogroups.com, Avi Bryant <avi at b...> wrote:
> 
> On Feb 15, 2004, at 12:54 AM, ducasse wrote:
> 
> > avi
> >
> > have you looked at F-script and the OOPAL model presented at
OOPSLA 
> > last year by philippe mougin.
> > Because I still would like to see if this can be introduced in
squeak 
> > with/without modifying the vm. I just have to
> > find a good student and philippe is willing to help. I browsed
the 
> > objective-C code and this is not really complex.
> > http://www.iam.unibe.ch/~scg/Archive/Papers/Moug03aOOPALOOPSLA.pdf
> 
> Yes, I've looked at F-script.  I don't see that we would need any
VM 
> modifications to support it, just some compiler extensions.  We
just 
> define, eg,
> 
> x @foo: y
> 
> to be syntactic sugar for
> 
> x collect: [:ea | ea foo: y]
> 
> and
> 
> x foo:@ y
> 
> to be syntactic sugar for
> 
> y collect: [:ea | x foo: ea].
> 
> x @foo:@ y then needs to be
> 
> x collect: [:eaX | y collect: [:eaY | eaX foo: eaY]]
> 
> and so on.  I haven't thought yet about what would happen with @@,
but 
> I expect it should still basically be a macro expansion to sends of 
> #collect:.
> 
> We could also use DNU to support his "implicit message patterns",
which 
> would interpret "x foo: y" as "x @foo:@ y" if they were both
Arrays, 
> but personally I would rather do without that.