- Haskell-prime - Haskell.org

Re[2]: Stand-alone deriving declarations added
by Bulat Ziganshin 10 Oct '06

10 Oct '06

Hello Simon, Friday, October 6, 2006, 11:41:21 AM, you wrote: > | declarations. The basic reason for maintaining a syntactic > | distinction between instance declarations and deriving declarations > | is to make the programmer aware of the restrictions of the deriving > | mechanism. unfortunately i don't see this whole message. but i disagree with this statement - imho, using several different mechanisms for deriving built-in classes, defining default instances, automatic generation of instances by TH, generic class definitions and automatic deriving for newtypes just confuse programmers and force to change code when one mechanism is replaced with another (say, when Typeable becomes built-in class instead of TH-generated one). so, i propose to leave only two forms of automatic instance definitions: - bundled with type definition: 'data ... deriving' clause - decoupled from type definition: 'instance Class Type' clause both forms should be allowed to be used with any class that may be automatically derived: 1) built-in classes Eq, Ord... 2) any class derived for newtype 3) class that has default definitions for all its methods: class (Enum a) => SuperEnum a where fromSuperEnum :: a -> Integer fromSuperEnum = toInteger . fromEnum 4) class that was defined using generics (currently GHC-only but i hope that future Haskell standards will support some form of Generic Haskell): class Generic a where f :: a -> a f (x :+: y) = ... f (x :*: y) = ... 5) i propose to extend GHC to allow TH generate default instance declarations. when one tries to derive XXX class, compiler should look up derivingXXX TH function and if it is defined, use this function to derive instance. so, the following: data A = B | C deriving(Binary) should be translated into data A = B | C $(derivingBinary 'A) Haskell is known as polymorphic language, but not generic one. It still lacks simple and powerful mechanism to generate class instances. Why i can't solve this problem completely, i hope that proposed extension may build some bridge to generic Haskell future, allowing at least GHC users to imagine that they work with compiler supporting user-controlled deriving mechanism imagine, for example, that you wrote serialization library with a Binary class. in first version, you have defined default Binary instance using generic classes: class Binary a where put (x :+: y) = ... put (x :*: y) = ... in the next version you have developed much more complex but efficient TH-based instance generation code: derivingBinary t = [| .... |] in third version, GHC comes with built-in Binary class support. and in the fourth version GHC includes Generic Haskell support so you can define default instance using GH. but independent of all these internal changes your clients continue to use the same deriving mechanism: data A = B | C deriving(Binary) is it not beautiful? :) | b) For deriving declarations, the compiler figures out the | constraints, whereas the programmer writes them for instance | declarations. it's real problem. in light of this i propose to extend 'deriving' mechanism so that it can derive in all the above-mentioned ways. plus, as Simon suggests, make the stand-alone 'deriving' clause the same syntax as 'instance' without constraints: data A = B | C deriving(Binary) data T a = T a deriving Binary (T a) where Binary deriving mechanism should by itself generate/check all necessary constraints -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Replacing and improving pattern guards with PMC syntax
by kahl＠cas.mcmaster.ca 04 Oct '06

04 Oct '06

One of the problems of pattern matching in Haskell is that it might well be regarded as not very declarative: function definition lines cease being generalisable equations, and the definition of the rewriting strategy involved in Haskell pattern matching extends over about three pages, no matter whether you look in the Haskell report, or for a definition of the ``functional rewriting strategy'' in the theoretical literature. <shameless plug> To fix exactly this problem was my original goal when I started developing a family of Pattern Matching Calculi, see http://www.cas.mcmaster.ca/~kahl/PMC/ . </shameless plug> (Other pattern matching calculi in the literature have different goals.) The original calculus, which I shall call ``PMC'' for the remainder of this message, is a confluent rewriting system with a normalising strategy that incorporates Haskell pattern matching --- the confluence proof has been mechanised using Isabelle. So far I never considered it important to devise a concrete syntax for PMC, but triggered by the current pattern guards thread on haskell-prime, I now try to give a PMC syntax that blends well with Haskell. PMC ``automatically'' includes the ``expression pattern'' of pattern guards, but organised differently, see below. I am now presenting a series of syntactic extensions to Haskell. without assuming that the reader is familiar with PMC, but I will also explain how these extensions relate with PMC. One of my gripes with Haskell pattern matching is that the anonymous variant, namely case expressions, has an application to an argument built in, and therefore does not by itself produce a function. However, lambda-abstraction already allows single-alternative pattern matching, so I propose to relax this to multi-alternative pattern matching: > length = \ > [] -> 0 > x : xs -> 1 + length xs (Lists of alternatives correspond to the ``matchings'' of PMC, and concatenation of those lists (using ``;'' or layout) corresponds to matching alternative in PMC. ``\ m'' then corresponds to ``{| m |}'' in PMC. ) For multi-argument pattern matching, I propose to allow nested matchings: > zip = \ > x : xs -> y : ys -> (x,y) : zip xs ys > _ -> _ -> [] > take' = \ > 0 -> _ -> [] > n -> { [] -> [] > ; x : xs -> x : take (pred n) xs > } This means that the alternative ``->'' now can have either an expression or a list of alternatives as its right argument. (Having an expression there corresponds to ``lifting'' $\leftharpoonup \_ \rightharpoonup$ in PMC.) Pattern guards now can be seen as a special case of alternatives-level argument application (``argument supply'' $\righttriangle$ in PMC). I find it useful to write the argument first, as in PMC. I see two options of writing argument supply in Haskell: either using new keywords, giving rise to the syntax production alt -> match exp with alts or using a keyword infix operator: alt -> exp |> alts (Using this kind of argument supply instead of pattern guards also has the advantage that multiple alternatives become possible.) I start with Simon Peyton Jones' standard example: > clunky env v1 v2 | Just r1 <- lookup env v1 > , Just r2 <- lookup env v2 = r1 + r2 > | otherwise = v1 + v2 This could now be written using either ``match _ with _'': > clunky env v1 v2 = \ > match lookup env v1 with > Just r1 -> match lookup env v2 with > Just r2 -> r1 + r2 > v1 + v2 or infix ``_ |> _'': > clunky env v1 v2 = \ > lookup env v1 |> Just r1 -> > lookup env v2 |> Just r2 -> r1 + r2 > v1 + v2 Note that the syntactic structure is different from pattern guards; here is the fully parenthesised version: > clunky env v1 v2 = \ > { lookup env v1 |> { Just r1 -> > { lookup env v2 |> { Just r2 -> r1 + r2 }}} > ; v1 + v2 > } Boolean guards are matches against True: > take = \ > 0 -> _ -> [] > n -> match n > 0 with > True -> > { [] -> [] > ; x : xs -> x : take (pred n) xs > } > _ -> error "take: negative argument" But Boolean guards can also be kept as syntactic sugar: > take = \ > 0 -> _ -> [] > n | n > 0 -> > { [] -> [] > ; x : xs -> x : take (pred n) xs > } > | otherwise -> error "take: negative argument" Now we have all the syntax in place --- PMC's ``failure'' is of course the empty alternative (allowed in Haskell 98). For the grammar, the relevant productions in Haskell 98 are: exp10 -> \ apat1 ... apatn -> exp (lambda abstraction, n>=1) | "case" exp "of" { alts } (case expression) alts -> alt1 ; ... ; altn (n>=1) alt -> pat "->" exp [where decls] | pat gdpat [where decls] | (empty alternative) gdpat -> gd "->" exp [ gdpat ] gd -> | exp This would change to the following, where I propose to rename ``alt'' to ``match'' for ``matching'' as in PMC, since this is now a full-fledged syntactic category of importance similar to that of expressions (PMC works essentially because of this separation of syntactic categories): exp10 -> \ { matchs } (lambda abstraction) | "case" exp "of" { matchs } (case expression) matchs -> match1 ; ... ; matchn (alternative, n>=1) match -> expr (result) | pat "->" { matchs } [where decls] (pattern matching) | pat gdpat [where decls] (pat. mat. w. Boolean guards) | (empty alternative) | "match" exp "with" { matchs } (pattern argument supply) gdpat -> gd "->" { matchs } [ gdpat ] gd -> | exp (case expressions would than be syntactic sugar: > case exp of {matchs} = \ match exp with {matchs} ) These productions imply that we would loose multiple abstraction: \ x y z -> 3 becomes \ x -> y -> z -> 3 . For reasons of declarativity, I am also tempted to argue that ``='' should only be allowed for one-line definitions, so we would write: > f 0 -> 1 > f n -> n * f (n - 1) An easy-to-remember motto for this could be ``if it can fall through, use ->''. This would of course break every single textbook and tutorial, so I won't insist... No matter whether with ``->'' or with ``='', the above would of course be syntactic sugar for: > f = \ > 0 -> 1 > n -> n * f (n - 1) LAWS ==== The most important nice thing is that we can now use equational reasoning for expressions involving pattern matching. The PMC laws (see the papers for more explanation) translate into the syntax presented above as follows (note that most of these equations are between matchings, i.e., between (lists of) alternatives, and only some are between expressions): --------------------------------------------------------------------- Failure as unit: > {- empty alternative -} ; alts = alts Failure lifting: > \ { } = undefined Result lifting: > \ { exp } = exp Argument propagation into matching: > (\ { alts }) exp = \ { match exp with { alts } } Argument propagation into expression: > match arg with { exp } = exp arg First match wins (no backtracking after first success): > exp ; alts = exp Failure-strictness of argument supply: > match arg with { } = {- empty alternative -} Distributivity of argument supply over alternative: > match arg with { alts1 ; alts2 } = > match arg with { alts1 } ; match arg with { alts2 } beta (v is a variable): > match arg with { v -> { alts } } = alts[v \ arg] -- substitution Match when matching the same constructor: > match c(e1,...,en) with {c(p1,...,pn) -> {alts}} > = match e1 with {p1 -> ... -> match en with pn -> {alts}} Mismatch when matching different constructors: > match c(e1,...,em) with {d(p1,...,pn) -> {alts}} > = {- empty alternative -} Strictness of matching against constructors: > match undefined with {c(p1,...,pn) -> {alts}} = undefined --------------------------------------------------------------------- Together with Strictness of function application in the function: > undefined arg = undefined -- already in Haskell , these laws, when oriented as rules, produce a confluent rewriting system, and the standard definition of strong head normal form induces a normalising strategy. Besides extending syntactic convenience even beyond pattern guards, adopting the abstract syntax of PMC would therefore also simplify the definition of the semantics of pattern matching in Haskell, and extend the scope of equational reasoning to pattern matching. For the concrete syntax I have no strong feelings, but hope that I provided a starting point for discussion. Wolfram

4 3

Pattern guards
by Yitzchak Gale 03 Oct '06

03 Oct '06

I would like to suggest a correction to ticket #56, "Pattern Guards". It is easy to show that every expression written using pattern guards can also be written in Haskell 98 in a way that is essentially equivalent in simplicity. (Proof below.) In my opinion, the Haskell 98 version below is more clear than the pattern guard version - it makes the monad explicit. Even if you disagree, I think it would be very difficult to argue that the difference is important enough to justify the extreme measure of adding new syntax to the language. Therefore, the first two items under "Pros" are false, and should be removed. The only remaining "Pro" is that the extension is well-specified, which has no value on its own. The purpose of Haskell' is to remove warts from Haskell, not add new ones. Pattern guards are a serious wart - they further overload syntax that is arguably already overused, as pointed out in the referenced paper by Martin Erwig and Simon Peyton Jones [EPJ]. I hope that there is still time to retract the evil decree of "definitely in" Proposal Status for this ticket. Regards, Yitz Proof: We first assume that the following declarations are available, presumably from a library: > data Exit e a = Continue a | Exit {runExit :: e} > instance Monad (Exit e) where > return = Continue > Continue x >>= f = f x > Exit e >>= _ = Exit e (Note that this is essentially the same as the Monad instance for Either defined in Control.Monad.Error, except without the restriction that e be an instance of Error.) > maybeExit :: Maybe e -> Exit e () > maybeExit = maybe (return ()) Exit Now given any function binding using pattern guards: funlhs | qual11, qual12, ..., qual1n = exp1 | qual21, qual22, ..., qual2n = exp2 ... we translate the function binding into Haskell 98 as: funlhs = runExit $ do maybeExit $ do {qual11'; qual12'; ...; qual1n'; return (exp1)} maybeExit $ do {qual21'; qual22'; ...; qual2n'; return (exp2)} ... where qualij' -> pat <- return (e) if qualij is pat <- e qualij' -> guard (qualij) if qualij is a boolean expression qualij' -> qualij if qualij is a let expression For a conventional guard: | p = exp we can simplify the translation to: when (p) $ Exit (exp) Simplifications are also possible for other special cases. This concludes the proof. Here are some examples, taken from [EPJ]: > clunky env var1 var2 > | Just val1 <- lookup env var1 > , Just val2 <- lookup env var2 > = val1 + val2 > ...other equations for clunky translates to: > clunky env var1 var2 = runExit $ do > maybeExit $ do > val1 <- lookup env var1 > val2 <- lookup env var2 > return (val1 + val2) > ...other equations for clunky > filtSeq :: (a->Bool) -> Seq a -> Seq a > filtSeq p xs > | Just (y,ys) <- lview xs, p y = lcons y (filtSeq p ys) > | Just (y,ys) <- lview xs = filtSeq p ys > | otherwise = nil translates to: > filtSeq :: (a->Bool) -> Seq a -> Seq a > filtSeq p xs = runExit $ do > maybeExit $ do > (y,ys) <- lview xs > guard $ p y > return $ lcons y $ filtSeq p ys > maybeExit $ do > (y,ys) <- lview xs > return $ filtSeq p ys > Exit nil Note that in this case, the Maybe monad alone is sufficient. That eliminates both the double lookup and the double pattern match, as discussed in [EPJ]: > filtSeq :: (a->Bool) -> Seq a -> Seq a > filtSeq p xs = fromMaybe nil $ do > (y,ys) <- lview xs > return $ if (p y) > then lcons y (filtSeq p ys) > else filtSeq p ys

10 21

All Monads are Functors
by Jon Fairbairn 02 Oct '06

02 Oct '06

I find myself dismayed that the mathematical relationship between Monads and Functors isn't available in Haskell98; if I use fmap in a Monad m=>... typed function, I get an extra Functor m required in the context, but not only are all mathematical monads functors, any instance of Monad has fmap in the form (>>= return . f), so it's annoying. There has been discussion in the past about whether Monad should be defined as > class Functor m => Monad m where ... (or some other means of making all Monads instances of Functor) I think the general consensus on the libraries mailing list in this thread http://thread.gmane.org/gmane.comp.lang.haskell.libraries/2815/focus=2815 which refers to this: http://www.cs.chalmers.se/~rjmh/Haskell/Messages/Display.cgi?id=444 was that it would be a good thing, but it breaks Haskell98 programmes. Surely Haskell' can get this right? On haskell prime I can find http://thread.gmane.org/gmane.comp.lang.haskell.prime/1328/focus=1427 which agrees with me, but I don't see a definite decision either there or in the Trac. I'd favour the above method as most conservative in terms of the language, but I'm not too fussed how it happens. Jón -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk

11 17

Re: [Haskell] Replacing and improving pattern guards with PMC syntax
by kahl＠cas.mcmaster.ca 02 Oct '06

02 Oct '06

Brandon, > Both of these constructs amount to minor syntactical overloading, > allowing lambda and "case" constructs in the expression grammar and the > match grammar with slightly different meanings. This seems to be pretty > similar to the way we already allow (Constr x y z) as an expression or a > pattern. I'm afraid this could easily lead to ambiguity on the grammar level and, independently, to confusion in the human head. But if these issues can be resolved, I currently do not feel strongly either way. Note however that > f xs = case xs of > (x : xs) -> case xs of > (y : ys) -> 1 > _ -> 2 and > g xs = case xs of > (x : xs) -> match xs with > (y : ys) -> 1 > _ -> 2 are different: f "01" = 1 g "01" = 1 f "0" = undefined g "0" = 2 f "" = 2 g "" = 2 f is in Haskell 98, and g can be rewritten using pattern guards: > g xs = case xs of > (x : xs) | (y : ys) <- xs -> 1 > _ -> 2 That is what I mean with ``fall-through'' --- and from this you see that you need an indicator for whether what is coming after the ``->'' is a matching or an expression. As long as the production alt -> expr is included, nothing that parses as an expression can be allowed to also parse as a matching according to a different production. In PMC, the corresponding production is match -> \leftharpoonup expr \rightharpoonup , so there, using ``case'' both for expressions and for matchings would ``only'' be confusing... But using delimiters is of course an option. (I also considered a different arrow for one of the two cases, for example ``|=>'' as in PMC, or even ``=>'', but I thought that the delimiter-less option was more ``Haskell-ish'', and with care in the grammar design can be made to work.) Several of your suggestions, including > I suggested whitespace rather than -> to separate sequential patterns could be feasible alternatives for the concrete syntax --- but we first need agreement on the abstract syntax. Perhaps the extension alt -> "match" exp "with" { alts } could be considered as an independent extension; this is more powerful than pattern guards, and probably less controversial than multi-alternative lambda. Wolfram

1 0

[brandonm@yahoo-inc.com: Re: [Haskell] Replacing and improving pattern guards with PMC syntax]
by kahl＠cas.mcmaster.ca 02 Oct '06

02 Oct '06

Brandon asked me to forward this --- I already posted a small clarification. Wolfram ------- Start of forwarded message ------- Date: Mon, 02 Oct 2006 00:07:17 -0700 From: Brandon Moore <brandonm(a)yahoo-inc.com> To: kahl(a)cas.mcmaster.ca CC: haskell-prime(a)haskell.org Subject: Re: [Haskell] Replacing and improving pattern guards with PMC syntax In-Reply-To: <20061002003307.15687.qmail(a)schroeder.cas.mcmaster.ca> kahl(a)cas.mcmaster.ca wrote: ... > So far I never considered it important to devise a concrete syntax for PMC, > but triggered by the current pattern guards thread on haskell-prime, > I now try to give a PMC syntax that blends well with Haskell. I think with some alterations your syntax would blend even better. In particular, it would be really nice to have a backwards-compatible syntax. > One of my gripes with Haskell pattern matching is > that the anonymous variant, namely case expressions, > has an application to an argument built in, > and therefore does not by itself produce a function. > > However, lambda-abstraction already allows single-alternativepattern matching, so I propose to relax this to multi-alternative > pattern matching: >> length = \ >> [] -> 0 >> x : xs -> 1 + length xs I'm with you here. Extending lambda to introduce a layout group of alternatives makes sense even without the rest of the changes to matching. This isn't completely backwards-compatible, but it's pretty close. While we're at it, why not have the identifier of a top level definition introduce a layout group of alternatives, rather than requiring the name to be repeated all the time. How about take 0 _ = [] _ [] = [] n (x:xs) = x : take (pred n) ns > (Lists of alternatives correspond to the ``matchings'' of PMC, > and concatenation of those lists (using ``;'' or layout) corresponds > to matching alternative in PMC. > ``\ m'' then corresponds to ``{| m |}'' in PMC. > ) > > For multi-argument pattern matching, > I propose to allow nested matchings: >> zip = \ >> x : xs -> y : ys -> (x,y) : zip xs ys >> _ -> _ -> [] This deviates from the current syntax of multi-argument lambda, and introduces overloading on ->. Perhaps -> could be reserved for "match and lift", and whitespace could separate several alternatives: zip = \ (x:xs) (y:ys) -> (x,y) : zip xs ys _ _ -> [] There is some tension in the current between argument lists which allow several arguments and require parentheses around constructor applications to delimit patterns, and case expression which match only one item, but without grouping. If we are trying to unify things, perhaps case could be extended to support matching several values together, perhaps separating expressions with commas in the head and using the syntax of a lambda for the cases. Perhaps '=' in function declarations vs. "->" for other matching could also be simplified somehow. I don't have any ideas here. >> take' = \ >> 0 -> _ -> [] >> n -> { [] -> [] >> ; x : xs -> x : take (pred n) xs >> } I'm not sure how to handle a case like this. Introducing layout at whitespace seems a bit excessive, but requiring explicit separators looks a bit heavy on punctuation next to the current grammar, where only records (and perhaps Maybe the '\' could be reiterated to introduce the layout group: take' = \ 0 _ -> [] n \[] -> [] (x:x) -> x : take (pred n) xs > > Pattern guards now can be seen as a special case of > alternatives-level argument application > (``argument supply'' $\righttriangle$ in PMC). > I find it useful to write the argument first, as in PMC. > > I see two options of writing argument supply in Haskell: > either using new keywords, giving rise to the syntax production > > alt -> match exp with alts Maybe reuse "case", unless a new keyword is needed to avoid confusion. > or using a keyword infix operator: > > alt -> exp |> alts > > (Using this kind of argument supply instead of pattern guards > also has the advantage that multiple alternatives become possible.) I'm not using -> to separate patterns, but some leading symbol is required to separate the last pattern from the expression. I like '|' from the current syntax, selected with hopes of incorporating and extending the current guard syntax. I'm pretty sure incorporating the existing guard syntax will require that the grammar keep track whether the last "bit" of the matching was a pattern or a guard (just like currently | switches from patterns separated by whitespace to a list of guards separated by commas). Pattern guards can be translated to matching plus argument supply, so argument supply needs to be part of the primitive matching syntax. I like the suggestion alt | exp |> alts It would be unambiguous but require unbounded lookahead to allow a case to begin with argument supply: foo :: [Int] -> [Int] foo = \lookup env v |> (Just r) [] -> [r] Given argument supply, we can sugar in the existing guard syntax by allowing alt | guard, guards, exp |> alts and alt | guards -> expr The sequence "->\" will transition from guards back to matching more arguments. It might be nice to abbreviate that to '\'. Guards can be eliminated with the translations alt | exp, guards ... ==> alt | exp |> True |guards alt | exp -> expr ==> alt | exp |> True -> expr alt | pat <- exp, guards ==> alt | exp |> {pat | guards ... } alt | pat <- exp -> expr ==> alt | exp |> pat -> expr > > I start with Simon Peyton Jones' standard example: > >> clunky env v1 v2 | Just r1 <- lookup env v1 >> , Just r2 <- lookup env v2 = r1 + r2 >> | otherwise = v1 + v2 I'd like to accepts this unchanged. I think the treatment of guards above will work. > This could now be written using either ``match _ with _'': > >> clunky env v1 v2 = \ >> match lookup env v1 with >> Just r1 -> match lookup env v2 with >> Just r2 -> r1 + r2 >> v1 + v2 > > or infix ``_ |> _'': > >> clunky env v1 v2 = \ >> lookup env v1 |> Just r1 -> >> lookup env v2 |> Just r2 -> r1 + r2 >> v1 + v2 Because I'm using space to separate patterns, I would require parentheses (or the pat <- exp sugar) clunky env v1 v2 | lookup env v1 |> (Just r1) , lookup env v2 |> (Just r2) -> r1 + r2 > Boolean guards are matches against True: >> take = \ >> 0 -> _ -> [] >> n -> match n > 0 with >> True -> >> { [] -> [] >> ; x : xs -> x : take (pred n) xs >> } >> _ -> error "take: negative argument" take = \ 0 _ -> [] n | n > 0 \[] -> [] (x:xs) -> x : take (pred n) ns This syntax has a pretty nice pronunciation, reading | as "such that", a comma as an "and" (between guards), and both space between patterns or '\' after a guard as "and" or "and then" (either way, introducing a pattern for another argument). This PMC stuff seems like a description/semantics for pattern matching. Hopefully my attempts at backwards-compatible syntax help people give the semantics a deeper look. Brandon ------- End of forwarded message -------

1 0

Re: [Haskell] Replacing and improving pattern guards with PMC syntax
by kahl＠cas.mcmaster.ca 02 Oct '06

02 Oct '06

Brandon Moore <brandonm(a)yahoo-inc.com> wrote in his answer to my PMC syntax proposal: > > Maybe the '\' could be reiterated to introduce the layout group: > > take' = \ > 0 _ -> [] > n \[] -> [] > (x:x) -> x : take (pred n) xs Definitely not, since the lambda gets us back into expressions, destroying the fall-through properties of matchings. (In this particular case this is no problem, but in general it would destroy fall-through.) > > > alt -> match exp with alts > Maybe reuse "case", unless a new keyword is needed to avoid confusion. We definitely need this construct to produce a matching (or ``alt''). If we use ``case'' here, then case expressions don't exist anymore. Wolfram

1 0

writing / status teams - call for volunteers
by isaac jones 30 Sep '06

30 Sep '06

Greetings, There are just a few days to go before the Haskell Workshop, and I'd like to be able to present the community with a report on our progress. With that in mind, I'm looking for some help during this busy time of year. The Haskell' committee has been voting on the wiki about the relative strength of various proposals. We're trying to find a group of proposals that is "definitely in" so that we can start the hard work of writing the report. Here's the survey: http://hackage.haskell.org/trac/haskell-prime/wiki/StrawPoll-2 The idea is that we want to make some tangible progress on actually writing the report, so we have selected some pretty non-controversial proposals. This is also to get a better idea of where there is and is not consensus. Below is the list of so-called "definitely-in" proposals, which is probably not quite correct. For instance, I don't think it's clear that MPTCs are definitely in, but the others look pretty good. Beside the proposal name is the group of committee members who have volunteered to write sections for so-called "definitely in" features. I have several requests for volunteers, which can be within or not within the committee: Would anyone else like to volunteer to write a section of the report for specific proposals below? Can anyone volunteer to do a survey of the current status of each of these proposals? We should try to figure out how far from done we are on all of them. I imagine that some things like concurrency are far from done, while other things like hierarchical modules and empty data declarations are pretty much done. Will anyone volunteer to write a status report for the community, with the goal of finishing the status report by the time of Haskell Workshop. This obviously isn't something fancy, just a summary of the items discussed, the current status on them, etc. This should all be on the list archives and on the wiki. A committee member is probably best suited for this, but anyone following the process closely should be able to do it :) Also, everyone should please think about this list as a whole; apply your right brain to consider whether it's a coherent and elegant set of proposals. > In > == > > #74: add some kind of concurrency: SM, HN, IJ > #35: add ForeignFunctionInterface: MC, SM > #49: add multi parameter type classes: MS > #60: add RankNTypes or Rank2Types: AL > #57: add polymorphic components: AL > #26: add ExistentialQuantification (existential components): AL, MS, SJT > #24: add HierarchicalModules: BH, IJ > #25: add EmptyDataDeclarations: BH, HN > #23: fix common pitfall with the do-notation and if-then-else: SM, HN, > #42: fix comment syntax grammar: SM > #56: add Pattern Guards: :( > #78: Add infix type constructors: BH, AL > Help w/ libraries (yay!): IJ, BH, SM, RP, DS peace, isaac

3 2

Haskell' Status Report
by Isaac Jones 28 Sep '06

28 Sep '06

Ravi Nanavati has very helpfully put together a status report for the Haskell Prime process. Please see this link, or read the pasted text below: http://hackage.haskell.org/trac/haskell-prime/wiki/Status' peace, isaac Summary: Since the Haskell Workshop last year, the Haskell community has documented (on this wiki) over 70 proposals for changes to Haskell 98. In March of this year, two subcommittees were established to focus on concurrency and the class system - two difficult areas that are important to the success of Haskell'. The committee has also used StrawPolls to filter and discuss the universe of proposals that has been gathered. Based on the most recent straw poll, 12 proposals (listed in the table at the bottom of the page) have been identified that are expected to get into Haskell' (over 2/3 of the committee in favor). An additional 19 proposals seem likely to get into Haskell' (based on slightly weaker criteria). Members of the committee conflict on 9 of the remaining proposals, and their status will be determined during the writing process. The remaining proposals are not expected to be part of Haskell'. Concurrency: The concurrency support in Haskell' will be based on the Control.Concurrent library, with minor modifications. There will be a thread-safe interface for mutable state, suitable for use in library code that does not otherwise use concurrency (though what it will be based on is an open issue). There will also be independent FFI annotations for specifying whether foreign calls are concurrent (with other Haskell threads) and reentrant. Bound threads will not be required by the concurrency standard, but they will be an allowed extension with a specified meaning. Open issues include whether standard will require preemptive concurrency, the syntax of the new FFI annotations and the memory-model semantics of IORefs. Class system: The work on the class system has focused on resolving the MultiParamTypeClassesDilemma. The core of the dilemma is that multi-parameter typeclasses are a popular extension that is strongly desired for Haskell'. However, many important uses of MPTCs (like the monad transformer library) require additional extensions to resolve ambiguities in their typechecking. Historically, FunctionalDependencies have been used for this purpose, but they are very tricky to implement and are also difficult to specify in a way that guarantees the termination of typechecking. AssociatedTypes are a possible replacement, but our current implementation experience with them is very limited. The subcommittee has explored several ways to resolve this dilemma (including restricted FDs, fast-tracked ATs and FDs as a "blessed" extension), but, so far, no consensus has emerged. Our current plan is to focus on writing other parts of the Haskell' standard, in the hopes that additional implementation experience with ATs will clarify the situation. Libraries: Thus far, libraries have been an underemphasized portion of the Haskell' effort (only 7 of the 70+ proposals have significant library content). However, there is a consensus that a revised standard library is an important part of the Haskell' effort. The current plan is to focus on starting to write the language portions of the standard first, since we have a substantial amount of work to do there which requires focused attention. After that effort is well underway, a companion library effort will begin. Several members of the committee have volunteered for this effort and additional volunteers will be needed. "definitely-in" Proposal Status: Description (Those volunteering to write this section): add some kind of Concurrency (IJ, SM) add ForeignFunctionInterface (MC, SM) add multi-parameter type classes (MS) add RankNTypes or Rank2Types (AL) add PolymorphicComponents (AL) add ExistentialQuantification (existential components) (AL, MS, SJT) add HierarchicalModules (IJ, BH, MW) add EmptyDataDeclarations (BH, HN) DoAndIfThenElse (SM, HN) fix comment syntax grammar (SM) add PatternGuards (RN, DS) add InfixTypeConstructors (BH, AL)

3 2

Trac Ticket "Component" Field?
by Ashley Yakeley 27 Sep '06

27 Sep '06

What do the various values of the "Component" field mean? Most issues have "Proposal", but some have "HaskellPrime". -- Ashley Yakeley Seattle WA

2 2