September 2006 - Haskell-prime

Here-docs in Haskell source
by Alistair Bayley 19 Oct '06

19 Oct '06

Apologies if this has been covered already... I've searched the haskell-prime list archive and not found anything on this. I'd like to submit a request for a fairly trivial feature: multi-line text literals in source, AKA here-docs. You know, like the ruby/perl/bash <<EOD...EOD, or python's triple-quotes, or C#'s @"...". My motivation: primarly for embedding SQL statements in program text. I'm sure there are plenty of other uses... I'm aware of the trailing-\-leading-\ option, but IMHO that's almost on a par with ++ ".." for usability: if you have a chunk of text you need to paste into your program as a text literal, you must modify every line. I know this can be automated, but it's still an extra step, and if you need to extract it for editing, you have to strip off the surrounding crud. Here's an old related thread, but I can't tell if some conclusion was reached: http://www.mail-archive.com/haskell-cafe@haskell.org/msg01343.html Alistair

9 16

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

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

Haskell Standard: Please email me if you want to join the committee.
by Isaac Jones 27 Sep '06

27 Sep '06

Greetings, As announced at the Haskell Workshop, the Haskell Prime process is running another committee selection round. We are specifically looking for people to write sections of the Haskell Report for the "definitely in" and "probably in" proposals, as described in: http://hackage.haskell.org/trac/haskell-prime/wiki/Status' Please email me if you think you would like to write sections of the report and be on the committee. Please tell me which of the "definitely in" or "probably in" sections you would like to help with writing. Also, anyone interested in the future of the language should sign up for the Haskell Prime mailing list if you aren't already: http://haskell.org/mailman/listinfo/haskell-prime peace, isaac

1 0

Exceptions
by John Goerzen 06 Sep '06

06 Sep '06

Hello, One thing that bugs me about Haskell is that exceptions are not extensible. I don't know how to craft a good solution, but perhaps if I explain the problem well, someone would come up with one. In a language such as Python or Java, and exception is an object. Let's consider Python for a quick example. Python has an IOError exception. So if I want to write a handler that deals with IOErrors, that's easy enough. Now maybe I want to do something like report socket errors specially. I could define a SocketError class that subclasses IOError. I could take this further, and define a URLError that subclasses SocketError. Now the beauty of it is that I can: * Have a handler that catches URLErrors only and does nothing special with SocketErrors or IOErrors. * Have a handler -- perhaps not even mine -- that catches and works with IOErrors. Since SocketError and URLError are descendants of IOError, that handler will *automatically* work if I raise a SocketError or a URLError. I can see no such mechanism in Haskell. Haskell's I/O exceptions have a certain defined set of errors that they can report, and I can't subclass them and make them more specific for my purposes if I want. Ditto for all the others. The Dynamic exception support is necessary and good to have, but it also under-documented and can be complex. And of course, they still suffer from the same lack of extensibility Are there any suggestions on how we might improve this situation in Haskell? -- John

6 12

Small note regarding the mailing list
by Christophe Poucet 03 Sep '06

03 Sep '06

Hello, Just a small request. Would it be feasible to tag the Haskell-prime list in a similar manner as Haskell-cafe? With regards, Christophe Poucet / vincenz

6 9