[m-dev.] Suggestion: default func-type/mode correspondence.

Ralph Becket rbeck at microsoft.com
Wed Jul 25 20:11:28 AEST 2001


> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> Sent: 25 July 2001 02:55
> 
> But I think I get the idea.  For higher-order function types,
> you want `ground' to mean that the function has the usual mode
> and determinism.

That's right.

> One consequence of this change is that higher-order functions with
> non-standard mode or determinism would become very much second-class
or
> even third-class objects.  If you have a list of such terms, for
example,
> you wouldn't be able to even call list__length on it.
> 
> Still, it may well be worth paying that price, in order to make
> higher-order functions that do have standard modes and determinism be
> truly first-class objects.

The full solution is to have proper mode polymorphism.  I think that
should be part of the language too as the "right" way to make everything
first-class.

However, on the grounds that (I believe) standard modes account for 90+%
of func lambdas, this proposal also makes sense and is orthogonal.

> Currently, h.o. functions can be put in collections, and can be gotten
> back out of them, but you can't call the resulting term without an
inst cast.
> With your proposal, h.o. functions with the standard mode/determinism
> could be put in collections, gotten back out of them, and called
without
> any inst casts, while h.o. functions with non-standard
mode/determinism could
> not even be put in collections unless you use an inst cast.

Or the collection insertion function has a matching mode or (better) a
polymorphic mode.

> The proposed change to the semantics of `ground' seems a bit
non-orthogonal
> to me, so I'm a little nervous about the consequences.  But from a
practical
> perspective it does look like this change would be a significant
improvement.
> So I give it a tentative thumbs up.

Great!  Who's currently working on the mode system?

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



More information about the developers mailing list