[m-dev.] for review: improvements for record syntax

[schachte at cs.mu.OZ.AU]

On  7 Dec, Simon Taylor wrote:
> With the current implementation you can't take the address of a
> function which does not have a single mode declaration.
> For a function `f/1' which does not have a single user-declared
> mode, `apply(f, X)' will give an error, `f(X)' won't. The
> transformation of `^/2' needs to produce function calls rather
> than applications of higher-order function terms where possible
> to avoid these errors.

So what I've been calling policy (1) would translate X ^ f(A, B) into
f(X, A, B).  Let's call this apply_front(f(A,B), X).  If we make the
restriction that the principal functor of the second argument of the
'^'/2 term must always be bound at compile time, then we can unfold the
call to apply_front inline, and everything works fine.

But Simon is arguing that ^ is useful in general as a concise version
of apply which puts the argument first and operation last.  So it
would look a little like a unix pipeline, allowing you to read it
left-to-right, rather than inside-out (which amounts to right-to-left).
So maybe we shouldn't have the known function name restriction.

We could still get the same benefit, though, by translating ^ into
apply_front/2.  The problems with this are that Mercury doesn't have an
apply_front/2 builtin (as I've argued before, it would have some
efficiency advantages over apply, so maybe it would be worth adding);
and some people might be confused that ^ pastes its extra argument
before the other arguments, while apply pastes extra arguments on the
back (OTOH, with policy (2) some people might be confused that the
argument that that is written first winds up being last).

As I understand Simon's point quoted above, Mercury's currently
forbids taking the address of a function that does not have a single
declared mode.  Therefore, simply translating X^F to apply_front(F,X)
and letting some later optimization phase fix it won't work.

This, together with the lack of an apply_front builtin, may mean that
for now it would be best to have the restriction that in the X ^ F form
the principal functor of F must be known at compile time.  That
restriction can always be relaxed later.  However, if it is decided 
that Mercury should never have an apply_front builtin, and we want to
keep the option of allowing the function name to be unknown, then I
think we'll have to go with policy (2) instead.

Is this a fair summary of the issue?

I guess on balance, I'd still argue for policy (1) with the known
function name restriction, and add the apply_front builtin (preferably
for all arities >= 1) later so the restriction can be dropped.


-- 
Peter Schachte                     The use of COBOL cripples the mind; its
mailto:schachte at cs.mu.OZ.AU        teaching should, therefore, be regarded
http://www.cs.mu.oz.au/~schachte/  as a criminal offense.
PGP: finger schachte at 128.250.37.3      -- E. W. Dijkstra 

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------