May be I am reading it wrong.... Shouldn't the second "instance" in "The instance's meaning is the meaning's instance" be plural as "meaning's instances" rather than "meaning's instance"? I am reading it similar to the "you are who you know" saying. It seems to say that the meaning of your data types ("The instance's meaning") is defined by the instances of known classes (with predefined meaning, defined by it properties, as in functor, monoid..) that is defined for your type. Daryoush 2009/2/19 Sjoerd Visscher

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 sjoerd@w3future.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, 20 Feb 2009 15:17:14 +0100 Achim Schneider wrote:

Conal Elliott wrote:

...

DRAFT version ___ comments please

Conal, please, PLEASE, never, EVER again use the word "meaning" if you actually mean "denotation". It confuses the hell out of me, especially the (I guess unintended) connotation that you analyse the meaning of a particular instance's existence on a cosmic scale.

It shouldn't confuse you. Using "means" for "denotes", and likewise "meaning" for "denotation", is correct English, and very common usage too. -- Robin

On Fri, Feb 20, 2009 at 9:12 AM, Achim Schneider wrote:

Robin Green wrote:

...

On Fri, 20 Feb 2009 15:17:14 +0100 Achim Schneider wrote:

...

Conal Elliott wrote:

...

DRAFT version ___ comments please

Conal, please, PLEASE, never, EVER again use the word "meaning" if you actually mean "denotation". It confuses the hell out of me, especially the (I guess unintended) connotation that you analyse the meaning of a particular instance's existence on a cosmic scale.

It shouldn't confuse you. Using "means" for "denotes", and likewise "meaning" for "denotation", is correct English, and very common usage too.

(length . denotations) "to mean" > (length . denotations) "to denote"

(read: "to denote" is more defined than "to mean")

Following your argument through, we should talk kinda like "hey, we do something with that thingy to do that-other thingy to that thingy over there". 99% of my former teachers would tear you to shreds... in mid-air (during lift-off).

I can't talk about the whole of English usage, but I never saw "meaning" in a mathematical context where "denotation" would work, too, except in Conal's writings.

...and that doesn't even include that my native language isn't English but German, in which "to mean" nounificates using another object: It translates to "Opinion" instead of "Denotation". "deuten" (to intepret, to point) is a very well-defined concept in German and doesn't like to be messed with.

The distinction is very clear in technical English but often disregarded in ordinary speech. http://consc.net/papers/intension.html is very informative. -gregg, your faithful half-baked philosophaster