HOM: Higher Order Messaging : Object

Hi

Can someone explain me on Higher Order Messaging and how it is used in
Java?

thanks
Srinivas Ivaturi,

srini <srinivas.ivaturi{}> wrote:
> Can someone explain me on Higher Order Messaging and how it is used in
> Java?

Higher Order Messaging is defined as messages that take other messages
as arguments. In a way, it is the OO ****og to Higher Order Functions
in functional programming languages (but different, because messaging
is different from function invocation).

The most comprehensive treatment is probably my OOPSLA paper:

www.metaobject.com/papers/ Higher_Order_Messaging_OOPSLA_2005.pdf

However, you can find varied discussion on the web.

To the best of my knowledge, HOM is not used in Java at all. There
have been attempts to implement HOM in Java, but these run afoul
of Javas strict typing regime.

Marcel

Marcel Weiher wrote in news:4q404aFld6b0U1{}news.dfncis.de:
> Higher Order Messaging is defined as messages that take other
> messages as arguments. In a way, it is the OO ****og to Higher
> Order Functions in functional programming languages (but
> different, because messaging is different from function
> invocation).
>
> The most comprehensive treatment is probably my OOPSLA paper:
>
> http://www.metaobject.com/papers/Hig...OPSLA_2005.pdf

This is a very interesting subject. I am a fan of functional
programming and this seems to combine the best of both object
oriented programming and functional programming.

Unfortunately, the paper goes a bit fast for someone new to the
concept and unfamiliar with the syntax that is being use. I am
especially confused by the 'each' message that is used like this:

alice addReport: sally reports each

This is supposed to be equivalent to sending alice the addReport
message with every report that sally has. Is this an example of HOM?
If so, which is the higher-order message? 'each' does not seem to
take any arguments, so I presume that it is by definition not higher-
order. 'each' is supposed to 'wrap its receiver in special marker
object', but surely it is objects that take actions, not messages. So
in other words, the receiver is supposed to wrap itself in an object.
That seems impossible even with the magic of HOMs.

Even assuming that 'each' can wrap its receiver, what exactly is the
receiver in this case? Is it sally? Is it sally's reports?

What is the argument to addReport in this case? Is it sally? Is it an
iterator created by 'each'? Does the implementation of addReport need
to know how to handle this situation?

The existence of the selectWhere message suggests an interesting
limitation to the technique. selectWhere only works for two levels of
message passing, such as:

[[[employees selectWhere] name] isEqual: {}"John"]

Where the test for each employee is like this:
[[employee name] isEqual: {}"John"]

But suppose we want a test like this:
[[[employee spouse] name] isEqual: {}"John"]

Now selectWhere seems inadequate.

Instead of selectWhere, I would have expected higher-order messages
to have message compositions. For example, one might use '.' to be a
message composition operator and then

[[[employees selectWhere] name] isEqual: {}"John"]

could become:

[[employees select] name . isEqual: {}"John"]

And we can also do:

[[employees select] spouse . name . isEqual: {}"John"]

Brendan Guild <dont{}spam.me> wrote:
> Marcel Weiher wrote in news:4q404aFld6b0U1{}news.dfncis.de:
>> The most comprehensive treatment is probably my OOPSLA paper:
>>
>> http://www.metaobject.com/papers/Hig...OPSLA_2005.pdf

> Unfortunately, the paper goes a bit fast for someone new to the
> concept and unfamiliar with the syntax that is being use.

Sorry to hear that :-(

> I am
> especially confused by the 'each' message that is used like this:

> alice addReport: sally reports each

Ahh...that's a typo in that draft. It should be

alice do addReport: sally reports each.

Sorry for the confusion, I think it was fixed in the final version.


> The existence of the selectWhere message suggests an interesting
> limitation to the technique. selectWhere only works for two levels of
> message passing, such as:

> [[[employees selectWhere] name] isEqual: {}"John"]

> Where the test for each employee is like this:
> [[employee name] isEqual: {}"John"]

> But suppose we want a test like this:
> [[[employee spouse] name] isEqual: {}"John"]

> Now selectWhere seems inadequate.

Yes, this is a limitation of HOM as presented.

There are ways of working around this limitation, for example accumulating
messages until a trigger ('go' ?) is received. However, when you explore
that avenue, I think you will find a lot more that doesn't work out the
way you'd want...

> Instead of selectWhere, I would have expected higher-order messages
> to have message compositions. For example, one might use '.' to be a
> message composition operator and then

You can't do that without changing the language, and it also becomes
somewhat difficult to figure out what exactly refers to what.

Marcel