> PS. Could somebody inform me what is the current status of
> multi-parametric classes?
GHC 3.01 supports multi-parameter type classes
in more or less the form described in the last section of
"Type classes: an exploration of the design space&quo
[Benchmark suckers and implementors only]
Chris writes ...
> While experimenting with the sorting algorithms that have been posted here
> recently I discovered that the benchmarks were being quite seriously distorted
> by the use of type classes to implement some of them. Even the us
While experimenting with the sorting algorithms that have been posted here
recently I discovered that the benchmarks were being quite seriously distorted
by the use of type classes to implement some of them. Even the use of `Ord a'
contexts instead of passing the compare method explicitl
A couple of people have asked about:
[2] W Burton, E Meijer, P Sansom, S Thompson, P Wadler, "A (sic) extension
to Haskell 1.3 for views", sent to the Haskell mailing list
23 Oct 1996
I am enclosing a copy of the "(sic)" proposal below. In light of Simon's
proposal, the "(sic)"
Folks,
There's often been quite a bit of discussion on the Haskell mailing list
about extensions of type classes. Erik Meijer, Mark Jones and I have
written a draft paper that explores the type-class design space, discussing
the various design decisions one must make, and their consequ
k for formal
details). The system presented there uses two forms of predicates (or
type classes, if you prefer):
r has l:t the record r has an l field of type t. Another way
to write this is to use a subtyping notation:
r <= { l : t }
r
Martin Odersky wrote:
..
> ... A good way to look at it is by comparing the
> role of record field labels with the role of other identifiers. In ML
> this correspondence made is very clear by writing the selection of
> field "l" as "#l r", i.e. the label acts like a function
> identifier. ...
I
It seems to be the season for records -- three proposals already and
I'm going to add a fourth one! Phil Wadler, Martin Wehr and I have
recently completed a paper that describes a radical simplification of
type classes. We restrict overloading to functions that have the
instance type as
work was in turn
inspired by an explicitly typed system (dating from around 1989-1990, I
believe) that was studied by Harper and Pierce. Independently, Ohori
published similar ideas (but without making the connection with type
classes) at POPL 92, and has distributed an implementation (a modified
If you seen this before I apologise I believe I sent it to the local
news group instead of Haskell. >:-|
Even without records you can get some oop benefits out of "Haskell"
(actually gofer and I believe hbc) using Constructor Classes.
My problem has been that I normally write my programs with
Here's a thought, engendered by a glass of beer in the Lamplighter's pub
in Gastown, Vancouver by John Hughes, Lennart Augustsson, and Simon PJ:
type classes can model extensible records.
Suppose we want to define a record for a person:
record Person = { Age : I
Simon suggests that:
| type classes can model extensible records.
Indeed, they can, and in several different ways, depending on the kind
of extensible records that you want to give the programmer. The particular
system that Simon outlined is pretty close to a proposal for `structures in
In connection with the current debate about modules and classes, I will
describe the view we are trying to develop in Brisk, and then describe how
this gives a slightly different perspective on the global instance property at
the end.
We are trying to develop a meaning for overloading, including
Phil writes:
> GLOBAL INSTANCE PROPERTY: if an instance exists of a given
> class at a given type, this instance is in scope everywhere
> that the class and type are in scope.
>
> If this was not the case, then the point at which overloading was
> resolved (definition point or
Ian Holyer and Will Partain have both argued that the interaction
between type classes and the module system could be improved. I have
no doubt that they are right.
It may help to explain some of the motivation behind the current
system. As Haskell is designed currently, the following
At last, an issue that I understand a bit.
Phil Wadler writes:
It may help to explain some of the motivation behind the current
system. As Haskell is designed currently, the following property is
satisfied:
GLOBAL INSTANCE PROPERTY: if an instance exists of a given
> Joe's example work as is. As I think it should. I havn't tried
> with ghc.
It compiles perfectly with ghc. Like Lennart, I don't see why it
shouldn't!
Kevin
Joe writes:
I forgot to mention that I did try it with hbc:
... transcript of working program omitted ...
That's surprising! I'd be interested to know if `maptry' works,
since in that case it makes sense to run the program, as well
as type it. Cheers, -- P
Joe writes:
| Phil Writes:
|
| | The closest one can come is
| |
| |class G a where
| |g :: a -> Bool
| |g x = g [x]
| |
| |instance G Int
| |instance G [Int]
| |instance G [[Int]]
| |...
| |
| |which requires an infini
Tobias Nipkow and Simon Finn were both kind enough to point
out that my Trie example was wrong, in that it is perfectly
typeable in ML (or Haskell).
Tries are like Mark's datatype X. The untypeable version is like
Mark's datatype Y.
data Try a = Atom a | List (Try [a])
mapt
Phil's (Robin Milner's ??) example typechecks in ML.
%Incidentally, there has been a lot of work done on Milner's type
%system extended to allow polymorphic recursion; this system is
%sometimes called ML+. One motivating example -- which I first
%heard from Milner -- is:
%
%
gow Haskell), or are not free,
or require less naive implementation techniques (generating one
function body for each monomorphic instance at which a polymorphic
function is used).
The sad thing about Haskell's type classes is that they did not come
for free: adding a function declaration
I haven't tried it in Haskell,
but it should either be illegal or cause the type-checker to enter an
infinite loop. (Hmmm! Maybe someone should try it ...)
Yes, after all, everyone knows that a language is defined by its
implementation... (:-)
-Paul
Phil writes:
| Joe writes:
|
| | Phil Writes:
| |
| | | The closest one can come is
| | |
| | |class G a where
| | |g :: a -> Bool
| | |g x = g [x]
| | |
| | |instance G Int
| | |instance G [Int]
| | |instance G [[Int]]
| | |
|
|This function is silly, as it never terminates, but there are less
|silly examples; see below. Note that the trick for translating
|polymorphic recursion into type classes (as described by Konstantin) no
|longer works here. The closest one can come is
|
|class G a where
|g :: a
)
This is an extension of the current definition of Haskell and, I
imagine, something that might one day be considered for inclusion
in a future version of the language. But we should probably think
carefully about the interaction with type classes. For example,
the following innocent looking prog
Consider the following recursive function binding:
> f [] = 0::Int
> f (x:xs) = 1 + f([]::[Int]) + f([]::[Bool]) + f xs
This binding is ill-typed since f is used in two different instances
of its polymorphic-to-be type. Indeed, the above declaration is
rejected by hbc, ghc, and g
The following paper, to be presented at POPL93, is now available by ftp:
Tobias Nipkow and Christian Prehofer
Type Checking Type Classes
We study the type inference problem for a system with type classes as in
101 - 128 of 128 matches
Mail list logo
