HOM - Higher Order Messages

> 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.
>
>

> 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.
>>
>
>
>
>

> 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
>
>

> 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]
>

> 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 ;)

>
> 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 -
>
>
>

> 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