<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
mso-style-link:"Code Char";
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:"Courier New";}
span.CodeChar
{mso-style-name:"Code Char";
mso-style-link:Code;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-fareast-language:EN-GB;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Anthony<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">You may be interested in Carlos Camarao’s interesting work. For a long time now he has advocated (in effect) making each function into its own type class, rather that grouping them into classes.
Perhaps that is in line with your thinking.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><a href="https://homepages.dcc.ufmg.br/~camarao/">https://homepages.dcc.ufmg.br/~camarao/</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Haskell-prime <haskell-prime-bounces@haskell.org>
<b>On Behalf Of </b>Anthony Clayden<br>
<b>Sent:</b> 06 October 2018 04:19<br>
<b>To:</b> Petr Pudlák <petr.mvd@gmail.com><br>
<b>Cc:</b> haskell-prime@haskell.org<br>
<b>Subject:</b> Re: A question about run-time errors when class members are undefined<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On Sat, 6 Oct 2018 at 9:47 AM, Petr Pudlák <<a href="mailto:redirect@vodafone.co.nz">redirect@vodafone.co.nz</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">IIRC one of the arguments against having many separate classes is that a class is not a just set of methods, it's also the relations between them,<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Hi Petr, I was talking about splitting out Haskell's current class hierarchy as a step towards doing away with classes altogether. If your language insists on methods being held in classes, that's just tedious bureacracy to invent class
names.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The relations between classes (including between single-method classes) can be captured through superclass constraints. For example, in the Haskell 2010 report<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">class (Eq a, Show a) => Num a where ...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">such as the important laws between `return` and `>>=`. And then for example a class with just `return` doesn't give any information what `return x` means or what should be its properties.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Then make Bind a superclass constraint on `return` (or vice versa, or both ways).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Just as the laws for Num's methods are defined in terms of equality<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">x + negate x == fromInteger 0 -- for example<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Talking about laws is a red herring: you can't declare the laws/the compiler doesn't enforce them or rely on them in any way. Indeed the Lensaholics seem to take pleasure in building lenses that break the (van Laarhoven) laws.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That said, one of really painful points of Haskell is that refactoring a hierarchy of type-classes means breaking all the code that implements them. This was also one of the main reasons why reason making Applicative a superclass of Monad
took so long. It'd be much nicer to design type-classes in such a way that an implementation doesn't have to really care about the exact hierarchy.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Yes that's what I was saying. Unfortunately for Haskell's Num class, I think it's just too hard. So a new language has an opportunity to avoid that. If OTOH Helium wants to slavishly follow Haskell, I'm wondering what is the point of Helium.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With Applicative, IIRC, refactoring had to wait until we got Constraint kinds and type families that could produce them. Would Helium want to put all that into a language aimed at beginners?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"> For example, in Haskell we could have<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">class (Return m, Bind m) => Monad m where<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">without any methods specified. But instances of `Monad` should be only such types for which `return` and `>>=` satisfy the monad laws.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">First: what does "satisfy the xxx laws" mean? The Haskell report and GHC's Prelude documentation state a bunch of laws; and it's a good discipline to write down laws if you're creating a class; but it's only documentation. Arguably IO,
the most commonly used Monad, breaks the Monad laws in rather serious ways because it imposes sequence of execution; and it would be unfit for purpose if it were pure/lazy function application.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Then: what do you think a language could do to detect if some instance satisfies the laws? (Even supposing you could declare them.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">And this would distinguish them from types that have both `Return` and `Bind` instances, but don't satisfy the laws.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">You could have distinct classes/distinct operators. Oh, but then `do` dotation would break.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Unfortunately I'm not sure if there is a good solution for achieving both these directions.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don't think there's any solution for achieving "satisfy the xxx laws".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">AntC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">čt 4. 10. 2018 v 3:56 odesílatel Anthony Clayden <<a href="mailto:anthony_clayden@clear.net.nz" target="_blank">anthony_clayden@clear.net.nz</a>> napsal:<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal"><span style="background:white">> We are adding classes and instances to Helium.</span><o:p></o:p></p>
</div>
<div>
<pre style="background:white;white-space:pre-wrap">> We wondered about the aspect that it is allowed to have a class instance<o:p></o:p></pre>
</div>
<div>
<pre style="background:white;white-space:pre-wrap">> of which not all fields have a piece of code/value associated with them, ...<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">I have a suggestion for that. But first let me understand where you're going with Helium. Are you aiming to slavishly reproduce Haskell's classes/instances, or is this a chance for a rethink?<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">Will you want to include associated types and associated datatypes in the classes? Note those are just syntactic sugar for top-level type families and data families. It does aid readability to put them within the class.<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">I would certainly rethink the current grouping of methods into classes. Number purists have long wanted to split class Num into Additive vs Multiplicative. (Additive would be a superclass of Multiplicative.) For the Naturals perhaps we want Presburger arithmetic then Additive just contains (+), with `negate` certainly in a different class, perhaps (-) subtract also in a dedicated class. Also there's people wanting Monads with just `bind` not `return`. But restructuring the Prelude classes/methods is just too hard with all that legacy code. Even though you should be able to do:<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">class (Additive a, Subtractive a, Negative a, Multiplicative a, Divisive a) => Num a<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">Note there's a lot of classes with a single method, and that seems to be an increasing trend. Historically it wasn't so easy in Haskell to do that superclass constraints business; if it had been perhaps there would be more classes with a single method. Then there's some disadvantages to classes holding multiple methods:<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">* the need to provide an overloading for every method, even though it may not make sense<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"> (or suffer a run-time error, as you say)<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">* the inability to 'fine tune' methods for a specific datatype [**]<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">* an internal compiler/object code cost of passing a group of methods in a dictionary as tuple<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"> (as apposed to directly selecting a single method)<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">[**] Nats vs Integrals vs Fractionals for `Num`; and (this will be controversial, but ...) Some people want to/some languages do use (+) for concatenating Strings/lists. But the other methods in `Num` don't make any sense.<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">If all your classes have a single method, the class name would seem to be superfluous, and the class/instance decl syntax seems too verbose.<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">So here's a suggestion. I'll need to illustrate with some definite syntax, but there's nothing necessary about it. (I'll borrow the Explicit Type Application `@`.) To give an instance overloading for method `show` or (==)<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">show @Int = primShowInt -- in effect pattern matching on the type<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">(==) @Int = primEqInt -- so see showList below<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">That is: I'm giving an overloading for those methods on type `Int`. How do I declare those methods are overloadable? In their signature:<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">show @a :: a -> String -- compare show :: Show a => a -> String<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">(==) @a :: a -> a -> Bool<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">Non-overladable functions don't have `@a` to the left of `::`.<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">How do I show that a class has a superclass constraint? That is: a method has a supermethod constraint, we'll still use `=>`:<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">show @a :: showsPrec @a => a -> String -- supermethod constraint<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">show @[a] :: show a => [a] -> String -- instance decl, because not bare a, with constraint =><o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">show @[a] xss = showList xss<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">(*) @a :: (+) @a => a -> a -> a<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">Is this idea completely off the wall? Take a look at Wadler's original 1988 memo introducing what became type classes. <o:p></o:p></pre>
<div>
<pre style="background:white"><a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhomepages.inf.ed.ac.uk%2Fwadler%2Fpapers%2Fclass-letter%2Fclass-letter.txt&data=02%7C01%7Csimonpj%40microsoft.com%7C5ec7c3a23a9746bb154b08d62b3a7ba2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636743927613528630&sdata=vXgR1YLqw8ERzEbhVZBGr%2FpB5fMLMmYtnwt6Bpp4wGs%3D&reserved=0" target="_blank">http://homepages.inf.ed.ac.uk/wadler/papers/class-letter/class-letter.txt</a><o:p></o:p></pre>
</div>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">It reviews several possible designs, but not all those possibilities made it into his paper (with Stephen Blott) later in 1988/January 1989. In particular look at Section 1's 'Simple overloading'. It's what I'm suggesting above (modulo a bit of syntax). At the end of Section 1, Wadler rejects this design because of "potential blow-ups". But he should have pushed the idea a bit further. Perhaps he was scared to allow function/method names into type signatures? (I've already sneaked that in above with constraints.) These days Haskell is getting more relaxed about namespaces: the type `@`pplication exactly allows type names appearing in terms. So to counter his example, the programmer writes:<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">square x = x * x -- no explicit signature given<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">square :: (*) @a => a -> a -- signature inferred, because (*) is overloaded<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">rms = sqrt . square -- no explicit signature<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap">rms :: sqrt @a => a -> a -- signature inferred<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">Note the inferred signature for `rms` doesn't need `(*) @a` even though it's inferred from `square`. Because (*) is a supermethod of `sqrt`. `sqrt` might also have other supermethods, that amount to `Floating`.<o:p></o:p></pre>
<pre style="background:white;white-space:pre-wrap"><o:p> </o:p></pre>
<pre style="background:white;white-space:pre-wrap">> ... a run-time error results.<o:p></o:p></pre>
<pre style="background:white">><o:p> </o:p></pre>
<pre style="background:white">> Does anyone know of a rationale for this choice, since it seems rather unhaskell-like.<o:p></o:p></pre>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If you allow default method implementations (in the class, as Cale points out), then I guess you have to allow instance decls that don't mention all the methods. I think there should at least be a warning if there's no default method. Also
beware the default method might have a more specific signature, which means it can't be applied for some particular instance.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Altogether, I'd say, the culprit is the strong bias in early Haskell to bunch methods together into classes. These days with Haskell's richer/more fine-tuned typeclass features: what do typeclasses do that can't be done more precisely at
method level -- indeed that would _better_ be done at method level?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">AntC<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Haskell-prime mailing list<br>
<a href="mailto:Haskell-prime@haskell.org" target="_blank">Haskell-prime@haskell.org</a><br>
<a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell-prime&data=02%7C01%7Csimonpj%40microsoft.com%7C5ec7c3a23a9746bb154b08d62b3a7ba2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636743927613528630&sdata=%2FVDtNLEzevef69Qs9rzrd5V2lBJzMLjRAxBBYvbsPAs%3D&reserved=0" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>