Hi,
Thanks for this very interesting and inspiring paper. I'm certainly
going to try some other data types, and see what kind of
implementations you get when using the TCM property.
I was wondering if any of this could be automated, given the semantic
function? If not in Haskell, then could this be a nice basis for a new
language?
If something still needs to be cut, I'd consider much or even all of
chapter 8. I found the tone and style unfitting for the rest of the
paper, as it deals with the (imho) ugliness of bottom and strictness
issues, instead of the beautiful relations found in the rest of the
paper.
greetings,
Sjoerd Visscher
On Feb 19, 2009, at 4:21 AM, Conal Elliott wrote:
I have a draft paper some of you might enjoy, called "Denotational
design with type class morphisms".
Abstract:
Type classes provide a mechanism for varied implementations of
standard
interfaces. Many of these interfaces are founded in mathematical
tradition and so have regularity not only of *types* but also of
*properties* (laws) that must hold. Types and properties give
strong
guidance to the library implementor, while leaving freedom as
well. Some
of the remaining freedom is in *how* the implementation works,
and some
is in *what* it accomplishes.
To give additional guidance to the *what*, without impinging on
the
*how*, this paper proposes a principle of *type class morphisms*
(TCMs),
which further refines the compositional style of denotational
semantics. The TCM idea is simply that *the instance's meaning
is the
meaning's instance*. This principle determines the meaning of
each type
class instance, and hence defines correctness of implementation.
In some
cases, it also provides a systematic guide to implementation,
and in
some cases, valuable design feedback.
The paper is illustrated with several examples of type,
meanings, and
morphisms.
You'll find the paper at http://conal.net/papers/type-class-
morphisms/ .
I'd sure appreciate feedback on it, especially if in time for the
*March 2* ICFP deadline. Pointers to related work would be
particularly appreciated, as well as what's unclear and what could
be cut. This draft is an entire page over the limit, so I'll have
to do some trimming before submitting.
Enjoy, and thanks!
- Conal
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Sjoerd Visscher
sjo...@w3future.com
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
