Hi,
Thomas Hallgren writes:
> You can (almost) do this with Haskell 1.3 constructor classes. I enclose
> a module that gives you overloaded selector functions called part1,
> part2, part3, and so on, that work on all tuples sizes (up to an
> arbitrary limit, in the enclosed code chosen to be 4 :-).
> However, because the way constructor classes work in Haskell 1.3, it only
> almost works. For instance, I had to number the parts from right to left
> to get it to work. So, this turns out to be a good example where the rather
> annoying restrictions (or lack of expressiveness) that constructor classes
> have, pop up. Two problem are:
If you were prepared to use the records of Haskell 1.3 this problem could be
resolved simply by the fact that field ordering is arbitrary. Consider,
for example the following Haskell datatypes:
data Point = MkP {xP :: Int, yP :: Int}
data CPoint = MkCp {colour :: Bool, xCp :: Int, yCp :: Int}
Now using the same idea as Thomas we can define a class for selecting an
x component from a given record as:
class FieldX a where
x :: a -> Int
and two instances of this class, one for each of the datatype definitions.
instance FieldX Point where
x = xP
instance FieldX CPoint where
x = xCp
One important point concerns the result type of the member function x, which
has been fixed to Int, and thus, restricts the overloading of selector functions
to a fixed result type. There are a number of possible solutions to this
problem, the most obvious is to extend Haskell classes to multi-parameter.
> (And while I am at it...) It would of course also be nice to have proper
> record types with subtyping. This would provide the most general and
> convenient solution to the selector function problem, I suppose. Isn't
> it about time record types with subtyping were integrated into widely
> used functional languages?
It is hard to know exactly what is meant by record types and subtyping, in
that extensible records provide a form of subtyping corresponding to simple
inheritance models for object-oriented. For example, consider types for points
and colour points:
type Point = Rec {x:: Int, y :: Int}
type CPoint = Rec {colour :: Bool | Point},
where CPoint is defined simply as a Point type extended with an additional
field colour. The subtyping relationship between Point and CPoint can be
highlighted by considering a function to retrieve the x component of either
a point or colour point:
getX r = r.x
which in a system supporting extensible records might be assigned the type:
Rec {x :: a | r} -> a,
where ranges over all fields except x. Thus, the subtyping relationship
between Point and CPoint can be defined as:
CPoint < Point,
which asserts that CPoint contains at least all the fields present in Point.
The form of subtyping described above is weaker that the more general notion
proposed by Mitchell [Mit91], in which subtyping constraints over a variety
of different types, and the general notion of solving these constraints are
considered.
> The type inference problem has been solved
> many times over by now (see, e.g., Didier Remy's Projective ML), hasn't
> it? A problem then is how subtyping should be integrated with the
> Haskell class system. Wouldn't it be really great if someone solved
> that!
If subtyping is considered as above, then Mark Jones and myself have a paper
[GJ96] describing a type system for polymorphic extensible records as an
application of qualified types, which may be integrated directly into the
Haskell type system.
Many regards
Ben
@article{Mit91,
author = "John C. Mitchell",
title = "Type inference with simple subtypes",
journal = "Journal of Functional Programming",
year = "1991",
volume = "1",
number = "3",
pages = "245-285",
month = "July"}
@techreport(GJ96,
author = "Benedict R. Gaster and Mark P. Jones",
title = "A Polymorphic Type System for Extensible Records and Variants",
institution = "Computer Science, University of Nottingham",
year = "1996",
month = "November",
type = "Technical Report" ,
number = "NOTTCS-TR-96-3")
--------
Benedict R. Gaster.
Functional Programming Group, Nottingham University.
Category theory: This is how our children will program!
----------------------------------------------------------------------
[Moderator's note: If you did not receive the post that this is a
reply to, and would like it, then mail <[EMAIL PROTECTED]> with
"resend tuple mail" in the subject line. We have had DNS problems at
Glasgow.]
