From: kahl@cas.mcmaster.ca
To: johan.baltie@wanadoo.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Haskell class type simulation
Date: 21 Nov 2002 21:45:46 -0000 [thread overview]
Message-ID: <20021121214546.17359.qmail@schroeder.cas.mcmaster.ca> (raw)
In-Reply-To: <200211212213.14407.johan.baltie@wanadoo.fr> (message from Johan =?iso-8859-1?q?Balti=E9?= on Thu, 21 Nov 2002 22:13:14 +0100)
<johan.baltie@wanadoo.fr> wrote:
>
> I'm currently looking for a way to simulate the Haskell "class type" notion
> in OCaml i.e. the same kind of :
>
> class Eq a where
> (==), (/=) :: a -> a -> Bool
>
> class (Eq a) => Ord a where
> compare :: a -> a -> Ordering
> (<), (<=), (>=), (>) :: a -> a -> Bool
> max, min :: a -> a -> a
>
> For me it's a bit like module signature with an abstract type and an
> "extending" semantic and a type constraint.
We looked the other way in:
@InProceedings{Kahl-Scheffczyk-2001,
author = {Wolfram Kahl and Jan Scheffczyk},
title = {Named Instances for Haskell Type Classes},
booktitle = {Proc.\null{} Haskell Workshop 2001},
year = {2001},
editor = {Ralf Hinze},
volume = {59},
number = {2},
series = ENTCS,
note = {See also: \textsf{http://ist.unibw-muenchen.de/Haskell/NamedInstances/}},
abstract = {Although the functional programming language Haskell
has a powerful type class system,
users frequently run into situations
where they would like to be able to define or adapt
instances of type classes
only \emph{after} the remainder of a component has been produced.
However, Haskell's type class system
essentially only allows late binding
of type class constraints on free type variables,
and not on uses of type class members
at variable-free types.
In the current paper we propose a language extension that
enhances the late binding capabilities of Haskell type classes,
and provides more flexible means for type class instantiation.
The latter is achieved via \emph{named instances}
that do not participate in automatic context reduction,
but can only be used for late binding.
By combining this capability with the automatic aspects
of the Haskell type class system,
we arrive at an essentially conservative extension
that greatly improves flexibility of programming
using type classes and opens up new structuring principles
for Haskell library design.
We exemplify our extension
through the sketch of some applications
and show how our approach could be used
to explain or subsume other language features
as for example implicit parameters.
We present a typed lambda-calculus for our extension
and provide a working prototype type checker on the basis of
Mark Jones' ``Typing Haskell in Haskell''.}
}
Best regards,
Wolfram
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
prev parent reply other threads:[~2002-11-21 21:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-21 21:13 Johan Baltié
2002-11-21 21:45 ` kahl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021121214546.17359.qmail@schroeder.cas.mcmaster.ca \
--to=kahl@cas.mcmaster.ca \
--cc=caml-list@inria.fr \
--cc=johan.baltie@wanadoo.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox