IMO, the committee should not focus on most these at the moment, because there are easier wins to be had - most of the open proposed ones have problems that make the discussion veer from "Very Obvious" to "Not so obvious". I know they're popular, but doing this is going to require a lot more discussion. A few points: - MPTCs. I'm OK with this by itself but it's not very useful without some constituent thing like Fundeps or type families. Richard, when you say there's an incoherence problem, can you be more specific? The more recent one I was reminded of was that FlexibleInstances can violate coherence, but that's a bit more subtle - maybe that's what you meant? I'm not sure if it's enough to keep it out. See https://gist.github.com/rwbarton/dd8e51dce2a262d17a80 for an example. - OverloadedStrings are less trivial than you think. Because: $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -XOverloadedStrings Prelude> length "foo" <interactive>:3:1: No instance for (Foldable t0) arising from a use of ‘length’ The type variable ‘t0’ is ambiguous ... Yes, I know, the FTP, etc etc etc. However, that makes a lot of simple code examples break in the case of overloaded functions that can't pick the right base type. There's obviously still some back and forth to be done, perhaps the FTP could be refined for Haskell2020. Anyway, my point is this is less initially trivial than it might seem to some. - GADTs are an extension I like dearly, but I think they are also not so simple. I think the Haskell report is fairly careful, as it stands, not to dictate much about inference strategies. GADTs surface these changes, for example, by ensuring let is not generalized. I think the committee could come to something on this perhaps, but it is not so simple. Deviating from this is something we can decide to do, but not easily. - Richard touched on it only as an side, but GADT syntax would be excellent. I would even like it to be enshrined by the standard as the default (perhaps modulo ExistentialQuantification). In fact I like it so much that it gets its own bullet point. That's for another day, just saying. - Type families, I think, are not as well understood and have changed far too quickly, in recent memory, to talk about this early on, as Richard said. I think that at the moment we should focus on making the process easy so we can keep our motivation up. Taking on large extensions is going to lead to bikeshedding and drain people, I think, which would be a real bad thing to happen after so much hubbub. I know many people on the committee are probably going to have feelings similar to the above. If we are going to talk about "wholesale incorporation", there are many simplier, much more obvious extensions. Plus, these will give us a chance to go at the process and try to find something that works for us. Or at least makes us all equally unhappy (the definition of good compromise). Much easier to test out how we want things to go when the stakes are much lower. I like the list Michael Sloan suggested elsewhere, or something like it. Many many more obvious extensions to be had: - RecursiveDo - LambdaCase - TupleSections (surprisingly popular, in the "would use frequently if always on"-category, it seems) - GADTSyntax (already definitively asserted as great) - BinaryLiterals - EmptyCase - InstanceSigs - ParallelListComp I seem to remember MultiWayIf having some kind of weird interaction with the lexer to make it abide by the proper block rules, but I'd probably also vote for it anyway. I intentionally left off anything that didn't seem somewhat blindingly obvious, and some that you might think suspiciously absent I know for a fact someone might pipe up and say "But wait!" -- Anyway, the point is to get some easy wins. Maybe others are ones we incorporate wholesale too, but let's just target a couple really clear ones. The thread about the RFC/editing process is still ongoing, but I think we could easily add the above ones with only a couple rounds of intense, heated debate, and that would be a good warm up. Traditionally, I think proposals were actually sent including what were basically literal deltas to the Haskell Report, pretty much, including how it would be described and added. Obviously we want source control to do that now. I'd be willing to be a guinea pig and submit a couple of the above ones for some trial runs on the process, if people think this is an OK place to start. We'll probably have to nail the exact RFC method down, though, in the other thread on the list. I also probably wouldn't get to it until the end of this week, so that's likely for the best anyway. On Mon, May 2, 2016 at 8:33 PM, Richard Eisenberg wrote:

Great questions. Here's my take:

For something to be incorporated into the standard, we'd need to be able to give a concrete, precise description of how the extension changes the set of correct Haskell programs. We also need to consider how the extension changes properties of the language, like predictability of performance or class coherence.

For the four you mention, here are my thoughts:

MultiParamTypeClasses: Can't these be used to create incoherence? I seem to recall hearing this once. I'm in general in favor of including these, but would want to reflect on the coherence question a bit.

OverloadedStrings: This seems very straightforward. But it's quite easy to conceive of times when I wouldn't want this feature in the language. If the extension becomes part of the standard, is there a way to turn it off? If not, Haskell2020 would not be a conservative extension of Haskell2010.

GADTs: While GADTSyntax seems straightforward, GADT type inference is far from. Do we have a description of GADT type inference that doesn't rely on thinking about variable unification? Even if we're OK putting unification into the standard, GHC's current inference capabilities are still not very finely mapped. (Note that the inference algorithm in the OutsideIn paper is incomplete with respect to the specification in that paper.)

TypeFamilies: I think there's quite a bit more to understand about type families before they could be standardized. First off, they come in many flavors (associated, open, closed). Do we want to include all of the flavors? How do partial type families really operate? I wrote a blog post [1] exploring this topic and had more questions than answers. What about termination checking? Or do we want to allow non-terminating definitions and discard decidability of type inference?

Of course, I recognize that John picked just a few arbitrary popular extensions. But even these extensions have a lot of dark corners, and my answers above are just to highlight that there's real work to be done, even with very popular extensions.

Richard

[1]: https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/

On May 2, 2016, at 6:57 PM, "John Wiegley" wrote:

...

I wonder if there are GHC extensions we'd like to promote as features in the next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell landscape, such that it's hard to imagine a modern Haskell without them. For example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the Report, and how do we determine when it's a bad idea?

-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Doh, left off MultiParamTypeClasses from the list in the email. Though, as Richard mentions, apparently this should be carefully considered with regards to coherence. On Mon, May 2, 2016 at 7:41 PM, Michael Sloan wrote:

In this issue on the hpack tracker, I describe my swing at coming up with a conservative set of extensions:

https://github.com/sol/hpack/issues/94

The list I ended up with is:

LambdaCase, GADTSyntax, ScopedTypeVariables, TupleSections, BangPatterns, FlexibleInstances, FlexibleContexts, MultiWayIf, TypeOperators, FunctionalDependencies, BinaryLiterals, RecursiveDo, ParallelListComp, PartialTypeSignatures, EmptyCase, InstanceSigs

Not sure about FlexibleInstances, EmptyCase, or TupleSections (see the issue).

If some set like this is accepted, then that "just" leaves figuring out the set of more complicated type system extensions :)

-Michael

On Mon, May 2, 2016 at 3:57 PM, John Wiegley wrote:

...

I wonder if there are GHC extensions we'd like to promote as features in the next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell landscape, such that it's hard to imagine a modern Haskell without them. For example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the Report, and how do we determine when it's a bad idea?

-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

This question implicitly has two parts: 1) Are there GHC extensions which the Report ought to describe in their entirety? To this question, I would say "yes" - pretty much anything which can be done in that direction will be productive, it's more a question of what people are willing to put the work into. 2) Are there extensions which ought to stop being extensions? To this question, I would argue it would be best to leave it for a time when the extension is already fully described as an extension in the Report. It may also be best to leave the answer up to the implementations. It is much easier to argue for something like that once the extension has been on by default in GHC and all other implementations for a while and most everyone seems happy leaving it on. On May 2, 2016 23:45, "Gershom B" wrote:

I agree that GHC extensions should be the starting point for new additions, as changes to the report should be based on established implementations (to ensure that changes are implementable and to ensure that they work out well for users).

1) background reading

There were a few interesting threads on reddit the other day that may provide some fodder to think about.

First, there was a survey of what extensions that people found useful and would like incorporated, as well as their concerns:

https://www.reddit.com/r/haskell/comments/4fsuvu/can_we_have_xhaskell2016_wh...

(Feel free to disregard the confusion of how they described “Haskell2016” and the like for something closer to glasgow-exts-2016, as its extraneous to what makes this interesting).

Second, the summary thread on the results:

https://www.reddit.com/r/haskell/comments/4ggp8z/summary_of_the_xhaskell2016...

The summary results give a good indication of what extensions there might seem to be the most widespread sentiment to standardize.

This thread also gives a link to Reid Barton’s lovely example of how FlexibleInstances can be used to violate coherence: https://www.reddit.com/r/haskell/comments/2agy14/type_classes_confluence_coh...

The same trick is supposed to apply to MPTCs. (In both cases, I imagine there can be a “fixup” that would prevent this, but that’s for another discussion).

2) suggestions for proceeding

In any case, it seems to me (as a non-prime-committee member) that it would be good to proceed in two parallel tracks.

First: A victim^H^H^H^H^H^H volunteer to pick a particularly low-hanging fruit (lambdacase, tuple sections, binary literals) and try to do a test-run of the proposal process to work out the kinks and set an example for others to follow. Perhaps a few could be worked on by different people at once. (As a datapoint, here is I think how an accepted proposal looked under the H2010 process: https://prime.haskell.org/wiki/NoNPlusKPatterns) (And I see that Austin has already volunteered! wonderful!)

Second: Some high-level effort to categorize and pull together a dependency graph of the other extensions. A googledoc spreadsheet or a trello board might be a good “work arena” for this. I would want to separate extensions into for example buckets like “pure syntax” “typeclass related” “monad syntax” “deriving related” “higher-rank related” “record related” “concurrency related”. The idea would be that things in the same bucket would have a higher chance of interacting / potentially needing to be treated in tandem. That way, areas could be tackled at once, and the committee could “burndown” easy stuff, while perhaps individuals with expertise might want to try to work on the side to find “minimal, safe” paths through the thicket of complex extensions. (standardizing GADT syntax without yet adding type equality constraints to enable actual GADTs is a good example here. Another _might_ be for example allowing RankNTypes but specifying that compliant compilers need only accept such type signatures fully specified, but could optionally go above and beyond in inference, etc). Note that more complex proposals could always be worked out by interest groups working by themselves, and only presented to a larger audience once some kinks were ironed out, etc.

Cheers, Gershom

...

I wonder if there are GHC extensions we'd like to promote as features in

On May 2, 2016 at 6:57:46 PM, John Wiegley (johnw@newartisans.com) wrote: the

...

next report, as a starting point for discussing new additions.

There are a few GHC features that have become part of the regular Haskell landscape, such that it's hard to imagine a modern Haskell without them. For example, MultiParamTypeClasses, OverloadedStrings, GADTs, TypeFamilies, etc.

How much "work" is typically involved in promoting a feature to be in the Report, and how do we determine when it's a bad idea?

-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Hi. Just to add a few general points. There are different dimensions to evaluate GHC extensions for inclusion in the standard, and just making lists does not really reflect that. The two most important ones, I think, are: 1. Whether we think they're actually a good idea or not. 2. Whether we think they're feasible to specify in a sensible way. There are variations of these points (extensions that are perhaps possible to specify, but ugly in their current form; extensions that have subtle interactions with others; ...) In general, I am in favour on working on extensions for which we believe they're good ideas, and try to make progress, even if we cannot include them yet. So just as an example, if we think GADTs (and not just GADTSyntax) are in principle a good idea and should be in a future standard, then perhaps we can try to work out what exactly we feel would be needed to include them, but is still missing. Then even in times when no standardization process is active, people can look at this list of issues and try to work on them. I also think that we should be careful with straight-forward looking syntax extensions. Just because an extension is easy to specify should not make it an automatic accept either. The complexity of the language is already high. All this being said, I still have a personal list: BangPatterns ConstrainedClassMethods ConstraintKinds (?) Derive* (?) EmptyCase ExistentialQuantification ExplicitForAll ExplicitNamespaces ExtendedDefaultRules (?) FlexibleContexts FlexibleInstances GADTSyntax InstanceSigs KindSignatures NullaryTypeClasses Overloaded* (?) PartialTypeSignatures (?) RankNTypes ScopedTypeVariables StandaloneDeriving (?) TypeSynonymInstances TypeOperators (?) I probably forgot a few. For the ones listed with (?), I am aware of some problems, but I'd still be very happy to at least have some discussions about them and make some progress in the direction of future standardization, as I indicated above. Cheers, Andres On Tue, May 3, 2016 at 7:32 AM, M Farkas-Dyck wrote:

On 02/05/2016, Cale Gibbard wrote:

...

Are there extensions which ought to stop being extensions?

...

It may also be best to leave the answer up to the implementations. It is much easier to argue for something like that once the extension has been on by default in GHC and all other implementations for a while and most everyone seems happy leaving it on.

I think in many cases that would defeat the purpose of extensions. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

On 2016-05-04 at 06:48:38 +0200, wren romano wrote: [...]

Speaking of which, are things like the AMP and FTP under our purview or are they under the CLC?

I tried to clarify in the call-for-nomination and the formation announcement that the library part of the Haskell Report shall be formally under the CL(i)C's purview given their experience with designing and implementing the big AMP/FTP/MFP proposals. In fact, I'd like to think of the (extended) Prime Committee as being composed of two sub-committee's: CLiC & CLaC (i.e. the Core Library Committee and Core Language Committee). This gives each sub-committee a clear focus. Of course, there'll sometimes be interactions (like e.g. language-extensions/features to improve backward compatibility with Haskell2010) between the language and the library part, so CLiC & CLaC will have to talk to each other from time to time. It's also quite possible that CLaC members may pick-up work-items from the CLiC or vice-versa. I know some of you consider the "Prelude" module as being morally a part of the "language" rather than the library. But I'm sure the CLiC will exercise extreme caution when the holy-grail "Prelude" module happens to require adaptations and keep everyone in the loop. Not the least because somebody may have alternative ideas how to achieve the goal differently worth considering. -- hvr

| For example, much as I love GADTs and would be all for them being added | in some future language report, I do not feel they should be added this | time around. (Though I emphatically and wholeheartedly support adding | GADTSyntax.) The primary reason being that while the semantics of the | data types themselves is easy enough to define, there's no really | sensible way of specifying how type inference should work for them. GHC | has gone back and forth with a bunch of different inference methods | over the years, and I don't think that's really stabilized yet; Actually it has stabilised. The OutsideIn journal paper (http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/ind...) describes how it works, and has been absolutely stable for several years. (All the movement has been on other things: type families, kind polymorphism, etc.) I agree that the specification isn't entirely satisfactory, because it's a bit operational. But it's robust and stable. I'm not arguing for or against GADTs in the next iteration of Haskell. But I don't think that the ease or difficulty of specifying GADTs is going to change much, so waiting till next time may not help; useful as they are, a declarative specification for GADTs is tricky. Simon

There are many points I'd like to make in this discussion, but this one screams out the loudest: This thread is spiraling a bit out of control. I've seen useful conversations around many different extensions in here, but these conversations are sometimes only tangentially related. I'd personally much rather see us decide on a tool/process first, and then we can have someplace to have The GADT Discussion and another place to have The Overloaded Discussion, etc. Otherwise, we risk losing good points in this thread, and someone will have to comb through all of this to extract these good points. The discussion about what our goals are w.r.t. extensions -- whether to consider popularity, ease of specification, ease of implementation, making standard extensions, etc -- is, to me, more appropriate for this thread and this point in the process. So, might I humbly request that we focus our collective creative energies on having a stable process before getting into nitty-gritty details about extensions? Thanks, Richard On May 4, 2016, at 4:21 AM, Henrik Nilsson wrote:

Hi all,

...

For example, much as I love GADTs and would be all for them being added in some future language report, I do not feel they should be added this time around. (Though I emphatically and wholeheartedly support adding GADTSyntax.)

In my opinion, GADTs is one of the most important extensions of the Haskell type system over the past decade and definitely a sweet spot in the design space in terms of power vs. complexity, at least from a user perspective. I eagerly await Herbert's summary of of most used extensions (which I think will be an extremely important input when deciding how to go forward in general), but my definite impression is that GADTs (and not just GADT syntax) are used a lot.

Point taken about the difficulty of specifying GADT type inference declaratively. But as long as there at least is a way to standardise inference that works, and from what Simon said there is, I do think aiming to make GADTs an official part of Haskell 2020 should be a priority.

Best,

/Henrik

-- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

On 02/05/2016, Cale Gibbard wrote:

This question implicitly has two parts:

1) Are there GHC extensions which the Report ought to describe in their entirety? ...

2) Are there extensions which ought to stop being extensions? ...

I agree here, except as noted in my earlier mail in this thread. An extension i might like to no longer be an extension is NoMonomorphismRestriction, which i haven't yet seen brought up in this thread. I recognize it has some rationale for it, but i surely want this committee to at least re-evaluate its merits.

On Wed, May 4, 2016 at 2:51 AM, Dominique Devriese wrote:

As an outsider, I would like to suggest thinking about MonoLocalBinds. GHC has a rather convincing story (at least to me) that "(local) let should not be generalised" (since it becomes problematic in combination with several other language extensions) and the journal version of the OutsideIn(X) paper has empirical data that indicates it is not a big problem to remove. If there is a concern about backwards compatibility, perhaps the committee could deprecate local let generalisation in Haskell2020 and remove it in a subsequent iteration of the report?

FWIW, I'm against MonoLocalBinds. I understand the rational given in the paper, but I disagree with it. In my experience the medicine is worse than the disease. It used to be that where-clauses where a nice clean way of organizing code, especially for things like the worker/wrapper transform; but with MonoLocalBinds all the benefits of where-clauses are eliminated. For every local binding I'm forced to provide a type signature —because part of the whole *point* of factoring things out is that you're going to use them repeatedly, which for GADTs virtually guarantees the uses will be at different index types and therefore will require universal quantification— and these requisite type signatures almost entirely duplicate information provided by the signature for the primary/top-level binding. Indeed, in almost every situation I end up needing to manually provide type signatures which are identical to what let-generalization would have inferred. This repetition is not merely annoying, it actively harms legibility and maintainability of code. -- Live well, ~wren

On 2016-05-03 at 10:36:31 +0200, Augustsson, Lennart wrote:

I'd say there are extensions we should just adopt wholesale, but they are all of a very simple syntactic kind.

E.g., EmptyDataDecls

Btw, I have no idea why EmptyDataDecls keeps getting proposed for inclusion in the next report: `EmptyDataDecls` is one of the extensions that went into Haskell2010! :-) To quote Haskell2010, Ch. 12: | Those implementations are also encouraged to support the following | named language features: | | - PatternGuards, | - NoNPlusKPatterns, | - RelaxedPolyRec, | - EmptyDataDecls, | - ForeignFunctionInterface | | These are the named language extensions supported by some pre-Haskell | 2010 implementations, that have been integrated into this report. There's actually a few more deltas to H98 (like e.g. DoAndIfThenElse), so {-# LANGUAGE Haskell2010 #-} is not equivalent to {-# LANGUAGE Haskell98, PatternGuards, NoNPlusKPatterns, RelaxedPolyRec, EmptyDataDecls, ForeignFunctionInterface #-} But surprisingly this kind of information seems hard to find in the H2010 report.

Hello, I think it'd be great to get started by specifying a few simple extensions, such as the ones Lennart listed. Even though they are very well understood, and we have text about them in the GHC manual, we'd still have to think of how to integrate their descriptions with the rest of the report, and actually write the text. I'd be happy to start working on any of these as soon as we've decided what tools we'd like to use---I didn't follow the other thread closely, and I'd be happy to use whatever people are comfortable with (as long as it works on Linux, but I can't imagine that would be an issue). -Iavor On Tue, May 3, 2016 at 1:57 AM, Augustsson, Lennart < Lennart.Augustsson@sc.com> wrote:

Then I suggest we keep EmptyDataDecls!

-----Original Message----- From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] Sent: 03 May 2016 09:50 To: Augustsson, Lennart Cc: John Wiegley; haskell-prime@haskell.org Subject: Re: Are there GHC extensions we'd like to incorporate wholesale?

On 2016-05-03 at 10:36:31 +0200, Augustsson, Lennart wrote:

...

I'd say there are extensions we should just adopt wholesale, but they are all of a very simple syntactic kind.

E.g., EmptyDataDecls

Btw, I have no idea why EmptyDataDecls keeps getting proposed for inclusion in the next report: `EmptyDataDecls` is one of the extensions that went into Haskell2010! :-)

To quote Haskell2010, Ch. 12:

| Those implementations are also encouraged to support the following | named language features: | | - PatternGuards, | - NoNPlusKPatterns, | - RelaxedPolyRec, | - EmptyDataDecls, | - ForeignFunctionInterface | | These are the named language extensions supported by some pre-Haskell | 2010 implementations, that have been integrated into this report.

There's actually a few more deltas to H98 (like e.g. DoAndIfThenElse), so

{-# LANGUAGE Haskell2010 #-}

is not equivalent to

{-# LANGUAGE Haskell98, PatternGuards, NoNPlusKPatterns, RelaxedPolyRec, EmptyDataDecls, ForeignFunctionInterface #-}

But surprisingly this kind of information seems hard to find in the H2010 report.

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarke... for important information with respect to derivative products. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime