HOM - Higher Order Messages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

HOM - Higher Order Messages

francisco.j.garau
In Marcel's original paper it says:
        alice addReport: sally reports each

I suggested:
        alice addReport: sally reports all

Andreas is suggesting:
        alice addReport: eachOf sally reports

I liked the last one. But it would be tricky to implement. We don't want
to introduce any change into the language, so "eachOf" should be an
object. The only responsibility of this object is to create a HOM
trampoline. Hold on. What if eachOf is actually a class (but with the same
trampoline responsibility as before). Then we would have:
        alice addReport: EachOf sally reports

Ummhhh. Doesn't look very nice. Any of the first two alternatives looks
nicer to me - and very readable!

Blaine, I will look at the LazyCollections when I get a chance. Any
performance issues in your implementation?

Cheers,
Francisco


This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

Reply | Threaded
Open this post in threaded view
|

Re: HOM - Higher Order Messages

Wolfgang Eder
Hello,
what's wrong with:
alice addReports: sally reports.
Cheers, Wolfgang


[hidden email] wrote:

> In Marcel's original paper it says:
>         alice addReport: sally reports each
>
> I suggested:
>         alice addReport: sally reports all
>
> Andreas is suggesting:
>         alice addReport: eachOf sally reports
>
> I liked the last one. But it would be tricky to implement. We don't want
> to introduce any change into the language, so "eachOf" should be an
> object. The only responsibility of this object is to create a HOM
> trampoline. Hold on. What if eachOf is actually a class (but with the same
> trampoline responsibility as before). Then we would have:
>         alice addReport: EachOf sally reports
>
> Ummhhh. Doesn't look very nice. Any of the first two alternatives looks
> nicer to me - and very readable!
>
> Blaine, I will look at the LazyCollections when I get a chance. Any
> performance issues in your implementation?
>
> Cheers,
> Francisco
>
>
> This communication is for informational purposes only. It is not intended
> as an offer or solicitation for the purchase or sale of any financial
> instrument or as an official confirmation of any transaction. All market prices,
> data and other information are not warranted as to completeness or accuracy and
> are subject to change without notice. Any comments or statements made herein
> do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
> and affiliates.
>
>



Reply | Threaded
Open this post in threaded view
|

RE: HOM - Higher Order Messages

Blaine Buxton
In reply to this post by francisco.j.garau
>From: [hidden email]
>Blaine, I will look at the LazyCollections when I get a chance. Any
>performance issues in your implementation?

There probably is. I've never really have put it through the motions. The
code was mainly done as an experiment. I use doesNotUnderstand: to implement
the call to the result of the do, collect, or select. But, it should be a
one hit cost and not affect performance. LazyCollections didn't perform as
well as raw collections on small collections, but performance got better the
bigger the collection.

There's some bugs probably lurking around the corner. I coded it after
reading a book on Haskell and then added the HOM stuff after reading that
paper. It was a fun experiment.
------------------------------------------------
Blaine Buxton, Mad Scientist In Training
http://www.blainebuxton.com

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/


Reply | Threaded
Open this post in threaded view
|

Re: HOM - Higher Order Messages

Klaus D. Witzel
In reply to this post by Wolfgang Eder
Hi all,

what about higher order messages with more than one argument, examples

        "copy the first n elements from old to new array"
        newArray #at: eachOf: (1 to: n) #put: withEach: oldArray

        "conditionally copy n elements from old to new array"
        newArray #at: eachOf: (1 to: n) #put:
                withEach: oldArray onlyIf: [:index :element | element notNil]

When using colored syntax the hash sign can disappear in favor of a nice  
color.

The term (newArray #at:) can be read like a Binary Higher Order Message,  
both by the compiler and the developer. So eachOf: would be sent to  
(newArray #at:), resp. eachOf:withEach: would be sent to (newArray  
#at:put:). Only less is more ;)

The example from below would then be (imagine it very nicely colored)
        alice #addReport: eachOf: sally reports

/Klaus

On Wed, 19 Apr 2006 14:38:43 +0200, Wolfgang Eder <[hidden email]>  
wrote:

> Hello,
> what's wrong with:
> alice addReports: sally reports.
> Cheers, Wolfgang
>
>
> [hidden email] wrote:
>> In Marcel's original paper it says:
>>         alice addReport: sally reports each
>>  I suggested:
>>         alice addReport: sally reports all
>>  Andreas is suggesting:
>>         alice addReport: eachOf sally reports
>>  I liked the last one. But it would be tricky to implement. We don't  
>> want to introduce any change into the language, so "eachOf" should be  
>> an object. The only responsibility of this object is to create a HOM  
>> trampoline. Hold on. What if eachOf is actually a class (but with the  
>> same trampoline responsibility as before). Then we would have:
>>         alice addReport: EachOf sally reports
>>  Ummhhh. Doesn't look very nice. Any of the first two alternatives  
>> looks nicer to me - and very readable!
>>  Blaine, I will look at the LazyCollections when I get a chance. Any  
>> performance issues in your implementation?
>>  Cheers, Francisco   This communication is for informational purposes  
>> only. It is not intended
>> as an offer or solicitation for the purchase or sale of any financial
>> instrument or as an official confirmation of any transaction. All  
>> market prices,
>> data and other information are not warranted as to completeness or  
>> accuracy and
>> are subject to change without notice. Any comments or statements made  
>> herein do not necessarily reflect those of JPMorgan Chase & Co., its  
>> subsidiaries and affiliates.
>>
>
>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: HOM - Higher Order Messages

Jon Hylands
On Thu, 20 Apr 2006 07:40:39 +0200, "Klaus D. Witzel"
<[hidden email]> wrote:

> newArray #at: eachOf: (1 to: n) #put:
> withEach: oldArray onlyIf: [:index :element | element notNil]

This is supposed to be more readable (and higher-order) than normal
Smalltalk syntax?

        newArray := oldArray select: [:each | each notNil]

Personally, I think the main thing driving stuff like this must be that
people can't remember how #inject:into: works.

Many many years ago, Kent Beck proposed the following rules for collection
interation, and I have used these rules faithfully since:

- the iteration variable is always called 'each'. You can add to that, so
it is 'eachItem' or 'eachName' or 'eachClass' or whatever.

- for #inject:into:, the block arguments are always sum and each, in that
order.

        #(1 2 3) inject: 0 into: [:sum :each | sum + each].
        #(1 2 3)
                inject: Dictionary new
                into: [:sum :each |
                        sum
                                at: each put: 'Number ', each printString;
                                yourself].

I never have to look up #inject:into to remember, because I just remember
that the arguments are sum and each, and the rest is obvious.

It seems like this (HOM) is a solution for a simple language, where you
can't do anything complicated. Blocks in Smalltalk can have arbitrary code,
and I very often use them that way when combined with the specialized
collection iterators.

Later,
Jon
--------------------------------------------------------------
   Jon Hylands      [hidden email]      http://www.huv.com/jon

  Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
           http://www.huv.com

Reply | Threaded
Open this post in threaded view
|

Re: HOM - Higher Order Messages

Chris Patrick Schreiner
That was a lot clearer!  Thanks...

chrisp

Den Apr 20, 2006 kl. 2:50 PM skrev Jon Hylands:

> On Thu, 20 Apr 2006 07:40:39 +0200, "Klaus D. Witzel"
> <[hidden email]> wrote:
>
>> newArray #at: eachOf: (1 to: n) #put:
>> withEach: oldArray onlyIf: [:index :element | element notNil]
>
> This is supposed to be more readable (and higher-order) than normal
> Smalltalk syntax?
>
> newArray := oldArray select: [:each | each notNil]
>
> Personally, I think the main thing driving stuff like this must be  
> that
> people can't remember how #inject:into: works.
>
> Many many years ago, Kent Beck proposed the following rules for  
> collection
> interation, and I have used these rules faithfully since:
>
> - the iteration variable is always called 'each'. You can add to  
> that, so
> it is 'eachItem' or 'eachName' or 'eachClass' or whatever.
>
> - for #inject:into:, the block arguments are always sum and each,  
> in that
> order.
>
> #(1 2 3) inject: 0 into: [:sum :each | sum + each].
> #(1 2 3)
> inject: Dictionary new
> into: [:sum :each |
> sum
> at: each put: 'Number ', each printString;
> yourself].
>
> I never have to look up #inject:into to remember, because I just  
> remember
> that the arguments are sum and each, and the rest is obvious.
>
> It seems like this (HOM) is a solution for a simple language, where  
> you
> can't do anything complicated. Blocks in Smalltalk can have  
> arbitrary code,
> and I very often use them that way when combined with the specialized
> collection iterators.
>
> Later,
> Jon
> --------------------------------------------------------------
>    Jon Hylands      [hidden email]      http://www.huv.com/jon
>
>   Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
>            http://www.huv.com
>
>


Reply | Threaded
Open this post in threaded view
|

Re: HOM - Higher Order Messages

Klaus D. Witzel
In reply to this post by Jon Hylands
Hi Jon

on Thu, 20 Apr 2006 14:50:20 +0200, you <[hidden email]> wrote:

> On Thu, 20 Apr 2006 07:40:39 +0200, "Klaus D. Witzel"
> <[hidden email]> wrote:
>
>> newArray #at: eachOf: (1 to: n) #put:
>> withEach: oldArray onlyIf: [:index :element | element notNil]
>
> This is supposed to be more readable (and higher-order) than normal
> Smalltalk syntax?
>
> newArray := oldArray select: [:each | each notNil]
>
No. Since it was explicitly asked for the first n elements, the correct  
translation is

        (1 to: n) with: oldArray do: [:index :each |
                each notNil ifTrue: [newArray at: index put: each]]

I believe that a good syntax coloring would help HOM off the ground and,  
as the example shows, helps saving message selectors and nesting of blocks.

But also and for sure, every good thing has its counterexamples ;)

/Klaus


Reply | Threaded
Open this post in threaded view
|

Re: HOM - Higher Order Messages

Bert Freudenberg-3

Am 21.04.2006 um 06:42 schrieb Klaus D. Witzel:

> Hi Jon
>
> on Thu, 20 Apr 2006 14:50:20 +0200, you <[hidden email]> wrote:
>
>> On Thu, 20 Apr 2006 07:40:39 +0200, "Klaus D. Witzel"
>> <[hidden email]> wrote:
>>
>>> newArray #at: eachOf: (1 to: n) #put:
>>> withEach: oldArray onlyIf: [:index :element | element notNil]
>>
>> This is supposed to be more readable (and higher-order) than normal
>> Smalltalk syntax?
>>
>> newArray := oldArray select: [:each | each notNil]
>>
> No. Since it was explicitly asked for the first n elements, the  
> correct translation is
>
> (1 to: n) with: oldArray do: [:index :each |
> each notNil ifTrue: [newArray at: index put: each]]
>
> I believe that a good syntax coloring would help HOM off the ground  
> and, as the example shows, helps saving message selectors and  
> nesting of blocks.
>
> But also and for sure, every good thing has its counterexamples ;)


TerseMan says

        (oldArray atAll: (1 to: n)) select: [:each | each notNil]

This is actual, working, regular Squeak code.

And it's a more Smalltalky way of expressing this, too - whenever I  
see #at: and #at:put: used directly in an iterative manner I suspect  
there must be a more elegant way to express it. This is the most  
severe shortcoming in your "translation", along with the necessity to  
create newArray before, which adds another superfluous line of code.

If you want to get rid of the block, you could implement #value: on  
Symbols as "^arg perform: self". Then you can write even more tersely:

        (oldArray atAll: (1 to: n)) select: #notNil

... which you might call a very lightweight HOM.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: HOM - Higher Order Messages

Edgar J. De Cleene
Bert Freudenberg puso en su mail :

> (oldArray atAll: (1 to: n)) select: #notNil
>
> ... which you might call a very lightweight HOM.

I like HOM idea.

What if you could have ?

newArray := (oldArray allElements: oldArray ) select: #notNil.


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Reply | Threaded
Open this post in threaded view
|

Re: HOM - Higher Order Messages

Klaus D. Witzel
In reply to this post by Bert Freudenberg-3
Thank you Bert for the explanatory example code!

Wrt your comment on "the necessity to create newArray before": this array  
existed before (after all, 'newArray' is just a variable name, not a new  
object) and is the target of the operation. So your suggestion does not  
fully translate.

[sorry, I seem to be quite alone defending HOM ;) anybody plEASE don't  
take my comments personal :-]

/Klaus

On Fri, 21 Apr 2006 14:28:44 +0200, Bert Freudenberg <[hidden email]>  
wrote:

>
> Am 21.04.2006 um 06:42 schrieb Klaus D. Witzel:
>
>> Hi Jon
>>
>> on Thu, 20 Apr 2006 14:50:20 +0200, you <[hidden email]> wrote:
>>
>>> On Thu, 20 Apr 2006 07:40:39 +0200, "Klaus D. Witzel"
>>> <[hidden email]> wrote:
>>>
>>>> newArray #at: eachOf: (1 to: n) #put:
>>>> withEach: oldArray onlyIf: [:index :element | element notNil]
>>>
>>> This is supposed to be more readable (and higher-order) than normal
>>> Smalltalk syntax?
>>>
>>> newArray := oldArray select: [:each | each notNil]
>>>
>> No. Since it was explicitly asked for the first n elements, the correct  
>> translation is
>>
>> (1 to: n) with: oldArray do: [:index :each |
>> each notNil ifTrue: [newArray at: index put: each]]
>>
>> I believe that a good syntax coloring would help HOM off the ground  
>> and, as the example shows, helps saving message selectors and nesting  
>> of blocks.
>>
>> But also and for sure, every good thing has its counterexamples ;)
>
>
> TerseMan says
>
> (oldArray atAll: (1 to: n)) select: [:each | each notNil]
>
> This is actual, working, regular Squeak code.
>
> And it's a more Smalltalky way of expressing this, too - whenever I see  
> #at: and #at:put: used directly in an iterative manner I suspect there  
> must be a more elegant way to express it. This is the most severe  
> shortcoming in your "translation", along with the necessity to create  
> newArray before, which adds another superfluous line of code.
>
> If you want to get rid of the block, you could implement #value: on  
> Symbols as "^arg perform: self". Then you can write even more tersely:
>
> (oldArray atAll: (1 to: n)) select: #notNil
>
> ... which you might call a very lightweight HOM.
>
> - Bert -
>
>
>



Reply | Threaded
Open this post in threaded view
|

RE: HOM - Higher Order Messages

Ramon Leon
In reply to this post by francisco.j.garau
> Thank you Bert for the explanatory example code!
>
> Wrt your comment on "the necessity to create newArray
> before": this array existed before (after all, 'newArray' is
> just a variable name, not a new
> object) and is the target of the operation. So your
> suggestion does not fully translate.
>
> [sorry, I seem to be quite alone defending HOM ;) anybody
> plEASE don't take my comments personal :-]
>
> /Klaus

Likely because Smalltalk is so expressive already, it'd take quite the
gain in expressibility to overcome the fact that it breaks the existing
regularity of the Smalltalk syntax.  Smalltalk isn't APL or J, not yet
anyway.