RE: TECH.ADV Generalising MAhO

[I.Alexander.bra0122@OASIS.ICL.CO.UK]

Nick:
> I think that in this case, all that is needed (and it is surprising this
> hasn't already taken place) is to replace <mex-operator>=MAhO <operand-3>
> with <mex-operator>=MAhO <mex> /TEhU/. After all, there is an algebra of
> functions; they can be composed of other functions, inverted, exponentiated,
> and returned from higher order functions.

Of course, why didn't I think of that?

> I suspect this will be problematic, possibly introducing ambiguities and
> inconveniences --- it is desirable that the unmarked form have its operators
> work at the operand level, rather than on functors; but I also think it is
> well and truly needed. I leave the mechanics to John on his return.

I think the simple cases take care of themselves, and the more
complicated ones yield to {vei ... ve'o} brackets.

> Given the proposed rule, Iain's piece becomes:
>
> ga'e.ybu goi li ma'o ge'olynau boi fy boi ma'o(ma'ofy(ma'oxy(ma'oxy te'u)
> te'u)te'u) (ma'ofy(ma'oxy(ma'oxy))) ro fy zo'u...
>
> or in the usual notation
> Y={lambda}f.(f(x(x)))(f(x(x))) {ALL}f:
> where the second (f(x(x))) is an argument of the function denoted by the
> first (f(x(x))).

You missed out a couple of "{lambda}x"s.

I'm not so keen on your use of {ma'o} on the inner operand.  I'd prefer
to keep {ma'o} as a _syntactic_ marker to signal that this is an operator
which is expecting some arguments, rather than just a semantic one to
say it's a function.  {ma'o xy.} isn't currently grammatical on its own,
and I don't see any real advantage in making it so.

ga'e.ybu goi li ma'o ge'oly.nau boi fy. ma'o (vei ma'o ge'oly.boi xy.
ma'ofy (ma'oxy.boi xy) ve'o) (ma'o ge'oly.boi xy. ma'ofy(ma'oxy.boi xy.))
ro fy. zo'u ...

Y={lambda}f.({lambda}x.f(x(x)))({lambda}x.f(x(x))) {ALL}f:

Iain.