Andreas -- Doesn't this fundamentally break Smalltalk's simple Object-Message syntax?

In the case of [each x add: y], each is not an object and x is not a message.

How about [x each add: y], etc.?

david

At 11:49 PM 2/15/2004 +0100, you wrote:
>And if you're into that please consider not using cryptic symbols. It seems
>much clearer to use a name, say "each" for this. Then you may write:
>
>> x @foo: y
>
>    each x add: y
>
>> x foo:@ y
>
>    x add: each y
>
>> x @foo:@ y then needs to be
>
>    each x add: each y.
>
>Cheers,
>  - Andreas
>
>----- Original Message ----- 
>From: "Avi Bryant" <avi at beta4.com>
>To: "The general-purpose Squeak developers list"
><squeak-dev at lists.squeakfoundation.org>
>Sent: Sunday, February 15, 2004 11:41 PM
>Subject: Re: A Lispy Forth for Smalltalk
>
>
>>
>> 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.
>>
>>
>
>
>
--
David Farber
dfarber at numenor.com