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

[Fergus Henderson]

On 08-Dec-2000, schachte at cs.mu.OZ.AU <schachte at cs.mu.OZ.AU> wrote:
> On  7 Dec, Fergus Henderson wrote:
> > On 07-Dec-2000, schachte at cs.mu.OZ.AU <schachte at cs.mu.OZ.AU> wrote:
> >> 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).
> > 
> > Hmm, I don't think that works, at least not if you intend apply_front
> > to be referentially transparent (i.e. to have a declarative semantics,
> > defined in terms of the meaning of its argument, rather than just
> > being syntactic sugar with only a transformational semantics that
> > depends on the syntactic form of its argument).
> >
> > In particular, if you write the goal
> > 
> > 	F = f(A, B), Foo = apply_front(F, X)
> > 
> > then I don't think that can mean the same as
> > 
> > 	Foo = f(X, A, B)
> > 
> > If it did, what would the type of `F' be?
> 
> Oh, it's referentially transparent, you just can't type it.  You'd have
> no problem implementing it soundly in Prolog (if Prolog supported
> functions, that is).  But your point is well taken:  it won't work in
> Mercury.  Bummer.

It's not just a weakness of the type system.  It's also because
Mercury gives higher-order terms real semantics, i.e. it treats
higher-order terms as relations and defines them to be equal iff they
define the same relation.  Your hypothetical Prolog implementation of
`apply_front' relies on the fact that in Prolog there's no real
higher-order terms, instead such terms are just ordinary Prolog terms
with no meaning other than their syntactic form and with syntactic
equality.

> > Also, I don't remember the supposed efficiency advantages, and I
> > suspect that they don't really exist and/or would not apply to the
> > MLDS back-end.
> 
> The efficiency advantage is that apply_front/N could be implement by
> code that just loads arguments 2 through N of the apply_front/N goal
> into argument registers 1 through N-1, and then enters a while loop that
> copies the closure arguments into argument registers beginning with N,
> and finally jumps to the closure's code.  With apply_front, you know at
> compile time what registers each argument is going to go in; not so with
> apply.
> 
> You're probably right that you couldn't take advantage of that using
> the MLDS back-end.  Maybe somehow using varargs technology?

For the MLDS back-end, each Mercury higher-order call compiles to
code which does one indirect function call and then one ordinary
function call (which in theory could often be a tail call), plus some
potential boxing/unboxing, e.g. for floating point arguments, since
the caller may be using a polymorphic type.  You may get some register
or stack slot shuffling between the two calls, if ordinary C function
call isn't inlined, but there's no loop, and each bit of code knows at
compile time exactly which registers or stack slots to load the
arguments into. 

> > I still prefer proposal (1) [with or without the function name
> > restriction] to proposal (2), because of the argument ordering, even
> > though `^' is not referentially transparent, and does not correspond
> > quite so directly to `apply'.
> 
> I don't see how you could ever implement policy (1) without the function
> name restriction.

Well, you just do the transformation as a syntactic transformation.
If you see `Term1 ^ Var(Term2)', you replace it with `Var(Term1, Term2)'.

> That's why I'm flip-flopping to support policy (2)
> now.  I think there is more to be gained by allowing first-class values
> on the right of ^ (even if not immediately) than is lost by a somewhat
> confusing argument order on accessor and setter functions.

OK, you've convinced me.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------