[m-dev.] subtyping proposal (repost)

[Mark Anthony BROWN]

Fergus Henderson writes:
> 
> I posted the following proposal in Febuary 1998.
> This seems relevant to the recent proposal for polymorphic modes,
> and also to the proposed reworking of the `reflection' interface,
> so I thought it would be a good idea to repost it.

Interestingly, I came close to reposting your proposal late last year
when I was trying to design a lazy data structure along the lines
of lazy_list.  I decided to think about the issue more before doing so,
so here are my thoughts now.

For those who are not familiar, the lazy list is like a normal list
except the tail is a closure which produces the real data (refer to
extras/lazy_evaluation).  This means that lazy lists cannot have inst
`ground', but have to have a higher order inst, as does any type which
contains a lazy list.  So any code that uses any data type which contains a
lazy list (or any lazy data structure, for that matter) cannot simply
use modes `in' and `out', but must use a custom designed mode or inst.
Even worse, if I change the implementation of a data structure so that
it uses laziness, chances are I will have to modify every bit of
code that uses that data structure.  This dependency on the
implementation makes lazy data structures unusable for Real Programming,
IMHO.

I believe the subtyping proposal will remove this dependency.  The
lazy list could be defined as a subtype of some other type.
Then it would be OK to refer to `ground' lazy lists, and the custom
designed modes or insts would not be required for code that uses
lazy lists.

> 
> Rationale:
> 	
> 	This language extension makes it simpler for users to use
> 	subtypes, without needing to know the mode system in quite so
> 	much detail.  It makes it easier to convert a program that
> 	didn't use subtypes into one that does, and avoids putting
> 	unnecessary clutter in the mode declarations.
> 

All of these reasons are true; but, IMHO, a more compelling reason
is that the "high level" concepts in a program, such as the definitions
of the main data structures, too easily wind up depending on "low level"
details like how some part of a data structure is represented.

> Counter-Rationale:
> 
> 	We already have one mechanism for subtypes/inheritence,
> 	namely type classes; do we need another one?
> 

Counter-Counter-Rationale:

	I don't see how typeclasses will help here.  I think that
	the proposed subtypes and typeclasses will complement
	each other nicely.

> -----------------------------------------------------------------------------
> 
> While I'm at it, here's an alternative syntax that might (or might not)
> be better.
> 
> Syntax:
> 
> 	:- subtype SubType < Type ---> Functors.
> 

Personally, I prefer this syntax.

Cheers,
Mark
-- 
Mark Brown, PhD student            )O+  |  "Another of Fortran's breakthroughs
(m.brown at cs.mu.oz.au)                   |  was the GOTO statement, which was...
Dept. of Computer Science and Software  |  uniquely simple and understandable"
Engineering, University of Melbourne    |              -- IEEE, 1994
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------