Talk:History of Haskell/Version 1

Comments on "The History of Haskell" (draft)

Please use the Wiki to add your comments here. Include your name and the date. You can do this with four tildes, like this: ~~~~.

To edit the page, you need to log in: click the login link at the bottom of the window. If you don't already have an account, the login page lets you create one in 30 seconds. See HaskellWiki:Contributing.

---

Administration

Simonpj 18:51, 14 July 2006 (UTC) Simon PJ. Here is an example comment

BerniePope I hope you don't mind, but I've taken the liberty of breaking this up into sections, so that it is easier to find out what has been said already. This seems to be especially useful for typos etc. Please feel free to add other sections if you think they are necessary. I've also made the page numbers bold, and put them into page order (where possible).

Title suggestions

JaredUpdike 20:38, 14 July 2006 (UTC) Other ideas for a title: The History of Haskell: Unsuccessfully Avoiding Success or something using the motto "Avoid success at all costs." Or perhaps Success Considered Harmful, or, A History of Haskell or Doomed to Succeed quoting Hoare (although this sounds somewhat self-congratulatory).

GaneshSittampalam 09:19, 15 July 2006 (UTC) I really like the "eager to be lazy" title.

BerniePope 13:59, 17 July 2006 (UTC) Subtitles: (not serious) "A pure type of fun, with no side-effects (except when bottoms are uncovered)". "From theorems to tools". "Doing lots of typing to avoid doing lots of work". "Beta reduction than destructive update".

Typos, spelling, grammar, formatting and expression

Malcolm 10:05, 20 July 2006 (UTC) (SLPJ: done) Typo? page 1, column 2, "version 1.0 dated 1 April 1988" seems to conflict with the later timeline (and several other mentions) which places the first version in April 1990.

BerniePope 15:42, 15 July 2006 (UTC) (SLPJ: done)Typo: page 2, column 2, "Rod Bustall" should be "Rod Burstall".

Greg Restall 09:55, 7 August 2006 (UTC) (SLPJ: done) Name: page 3, column 1, "Barclay Rosser" should be "Barkley Rosser".

BerniePope 15:42, 15 July 2006 (UTC) (SLPJ:done) Spelling: page 3, column 1, "confernce".

(SLPJ: wording improved) On page 4 after the list of goals, it seems that the following sentence ("We agreed to base it on an existing language, namely OL.") should be preceeded by a line break (it now starts on the same line as the sixth goal).

ChristianSievers 20:12, 25 July 2006 (UTC)(SLPJ: done) Expression. page 5, about Haskell 1.4: "list comprehensions were made applicable to arbitrary monads". I think when applied to a monad, they are no longer list comprehensions. If you don't want to mention monad comprehensions, maybe write that "l. c. were generalized to a. m."

ChristianSievers 20:12, 25 July 2006 (UTC) (SLPJ: done) Double word. page 7, first line: "can be sure that that f will not"

JaredUpdike 22:00, 14 July 2006 (UTC) (SLPJ: done) page 9 Section 3.8, last paragraph, syntax error: should be "Miranda is still in use today: it is still taught in some institutions", missing word. (Sec 4.2 This tradition was honed by Moses Schonfinkel and Haskell Curry, and came to be called currying. I half expected a joke following this, saying [it was] called currying, luckily, and not schonfinkeling.) Same section, typo: is a list of lists should be in a list of lists.

That joke would have been surpassed by reality, because the german word for currying is schönfinkeln. See Schönfinkeln. --MarcVanWoerkom 18:49, 16 July 2006 (UTC)

ChristianSievers 20:12, 25 July 2006 (UTC) (SLPJ: done) So in the section about currying, it should be Moses Schönfinkel (Umlaut!).

BerniePope 15:42, 15 July 2006 (UTC) (SLPJ: done) Expression. page 9. It says "Haskell did not adopt Miranda's abstract data types, using its module system instead." It is not clear whose module system it is using. Perhaps it should read "using a module system instead." ?

ChristianSievers 20:12, 25 July 2006 (UTC) (SLPJ: done) Missing word. page 10, end of section Infix operators: "are not used extensively enough to cause major problems."

BerniePope 15:56, 15 July 2006 (UTC) (SLPJ: done) Tense. page 12. Section 5.1, algebraic data types. It says "In general, every algebraic data type specified...", should that be "specifies" ? or perhaps even better "In general, algebraic data types specify" ?

(SLPJ: ToDo) Ruiz 12:04, 16 July 2006 (UTC) Comment. page 12. If I am not mistaken, the Fermat's Last Theorem example only generates (1,1,z) triplets.

Well, the example is wrong in many more respects than that. n need to be bigger than 3 for the example to relate to Fermat's Last Theorem. Furthermore, the list comprehension would generate 'counter examples' to the theorem, not solutions. I think it would be best if you chose a completely different example

BerniePope 16:15, 15 July 2006 (UTC) (SLPJ: done) Tense. page 13. Section 5.3 Abstract types. It says "This had the advantage ...". Perhaps it should be: "This has the advantage", since Miranda still exists, and the advantage still holds. Later in the same paragraph the expression about adopting the feature in Haskell is a bit awkward. Perhaps it could read: "It is not clear how to adapt Miranda's method of defining abstract data types to type classes, and that is one reason we chose a different solution." ?

BerniePope 16:27, 15 July 2006 (UTC) (SLPJ: done) Typo. Section 5.6, page 14 and in Bibliography. Godel's name in citation missing the 'o'.

No it's missing the 'ö'. It has an umlaut. Josef 13:33, 4 August 2006 (UTC)

BerniePope 05:41, 16 July 2006 (UTC) (SLPJ: done) Comment. page 15, column 1. "practical comprehensibility" is a bit of a mouthful. Perhaps "pragmatism" would suffice?

BerniePope 06:11, 16 July 2006 (UTC) (SLPJ: done) Typo (possibly). page 16. Section 6.4, multi-parameter type classes. "They gave the following example: second.". Should the "second" be there?

BerniePope 06:56, 16 July 2006 (UTC) (SLPJ: done)Typo, page 16. The code "n = (x + y)", perhaps drop the redundant parens?

BerniePope 07:19, 16 July 2006 (UTC) (SLPJ: done) page 17. Choice of identifier. In the code "f (MkT x f) = f x". Perhaps the inner or outer "f" should be renamed? Also, is there a more compelling example than this one?

Weihu 17:33, 16 July 2006 (UTC) (SLPJ: done) page 17. Duplication of words. "The the type qualification in this case" => "The type qualification in this case".

BerniePope 07:16, 16 July 2006 (UTC) (SLPJ: done) Typo. page 17. "patter-matching" -> "pattern-matching".

BerniePope 07:26, 16 July 2006 (UTC) (SLPJ: done) Expression. page 17. Perhaps drop "rather than explicitly". This is implied by the previous "happens implicitly".

BerniePope 07:38, 16 July 2006 (UTC) (SLPJ:done). page 18. In lexically scoped type variables, it says the type of xcons is "forall a. a -> a". Do you mean: "forall a . [a] -> [a]"?

ChristianSievers 20:12, 25 July 2006 (UTC) (SLPJ: done) Missing Article. page 18, section Generic Programming: "Haskell has served as the host language for a remarkable variety of experiments..."

Plareplane 01:13, 18 July 2006 (UTC) (SLPJ: done) Typo. page 20. "The input in the string to be parsed, and returns a list of parse results, consisting of the value parsed and the remaining unparsed string."

BerniePope 08:39, 16 July 2006 (UTC) (SLPJ: done) Typesetting. page 22. Sometimes the "IO monad" is written where "IO" is in typewriter font, and other times it is in times roman, and other times it is written "I/O". This may be an intentional distinction, but maybe the notation can be unified?

Weihu 20:36, 16 July 2006 (UTC) (SLPJ: done) Word missing. page 22. "So readFile a function that" => "So readFile is a function that".

ChristianSievers 18:20, 18 July 2006 (UTC) (SLPJ: done) Extra word. page 22. "An IO computation is a function that (logically) takes a the state..." Drop "a" or "the".

ChristianSievers 20:12, 25 July 2006 (UTC) (SLPJ: done) Double word. page 24, last sentence: "The first release was (0.10) was in December 1992..."

ChristianSievers 20:12, 25 July 2006 (UTC) (SLPJ: that's the way multi-para quotations are supposed to go.) Syntax. page 25. In the section about hbc, most ending quotation marks are missing.

JaredUpdike 04:27, 15 July 2006 (UTC) (SLPJ: done) page 25. Section 9.2 misspelling "existance" should be "existence" third to last paragraph. Sec. 9.5 , page 27, second to last paragraph. test bad should be test bed.

BerniePope 12:33, 16 July 2006 (UTC) (SLPJ: done) Typo. page 28. Section 10.2, paragraph 2. "who had by thus time" -> "who had by this time".

BerniePope 13:22, 16 July 2006 (UTC) (SLPJ: done) Missing word. page 30. Section 10.4.2 Observational debugging. It says "to track down bug location" -> "to track down the bug location".

BerniePope 05:07, 17 July 2006 (UTC) (SLPJ: done) Expression. page 30. Section 10.5 Testing tools. "If debugging tools ... -> "Whilst debugging tools ...". The "if" seems to be left hanging in the sentence.

BerniePope 05:30, 17 July 2006 (UTC) (SLPJ: done) Syntax. page 30. Section 10.5 Testing tools. In the definition of "prop_insert" you use "$" for infix application, and thus avoid some parens. I wonder whether it would be better to have the explicit parens instead? Non Haskellers may find the "$" style difficult to parse. Also, it would be more consistent with other example pieces of code in the paper.

Weihu 21:35, 15 July 2006 (UTC) (SLPJ: done) Typo: page 31, column 2, "a central them" should be "a central theme".

Malcolm 11:10, 20 July 2006 (UTC) (SLPJ: done) Typo: page 31, section 11.1.1 Parser Combinators. "folkolore" should be "folklore".

JaredUpdike 00:14, 18 July 2006 (UTC) (SLPJ: done) Typo: page 32 end of page. Unless my PDF reader is missed up (likely) "time = Beh (\t - t)" should be "time = Beh (\t -> t)".

JaredUpdike 00:18, 18 July 2006 (UTC) (SLPJ: done)Typo. page 33 Second paragraph, 11.2.2 "Arguably, in is better" should be "Arguably, it is better".

BerniePope 05:47, 17 July 2006 (UTC) (SLPJ: done)Typo. page 33. Section 11.2.1 Functional reactive programming. The instance declaration for Floating is missing "Behaviour a) where".

Josef 14:19, 4 August 2006 (UTC).(SLPJ: done) page 33 section 11.2.2, second to last paragraph. You write '... an approach based on a generalization of monads called arrows was discovered ...' You should have a reference to the section where you talk about Arrows, which currently is Section 6.6. Though see my comment further down on moving the section about arrows.

JaredUpdike 00:24, 18 July 2006 (UTC) (SLPJ: done)Typo. page 33. sec 11.2.3: First three sentences could perhaps be combined with colons and semicolons, i.e. "Lazy functional [snip]: firstly [snip]; secondly [snip]." or the the second and third sentence fragments might be provided with predicates.

JaredUpdike 00:31, 18 July 2006 (UTC)(SLPJ: done) Typo. page 34. sec. 11.2.3 end of first paragraph

Microsoft?".

should be

Microsoft?"

(omit period after quote).

GaneshSittampalam 09:18, 15 July 2006 (UTC) (SLPJ: done)Section 11.2.3 page 34 typo "unsagePerformIO".

BerniePope 06:44, 17 July 2006 (UTC) (SLPJ: done)Missing word (perhaps). page 34. Section 11.2.5 Summary. It says "... a DSEL is little than that." I have not heard that expression before, perhaps it was meant to be: "... a DSEL is little more than that."?

BerniePope 06:51, 17 July 2006 (UTC) (SLPJ: done)Typo. page 35. Section 11.3 Graphical user interfaces. "lacked the fully range of widgets" -> "lacked the full range of widgets".

BerniePope 06:54, 17 July 2006 (UTC) (SLPJ: done)Extra word. page 35. Section 11.3 Graphical user interfaces. "... and only implemented only part of the full interface."

Weihu 21:42, 16 July 2006 (UTC) (SLPJ: done)page 35: "invariably based on a imperative widget" => "invariably based on an imperative widget".

BerniePope 06:54, 17 July 2006 (UTC)(SLPJ: done) Typo. page 35. Section 11.4 Natural language processing. "Callaghan?s": there is a question mark where there ought to be an apostrophe.

(SLPJ: ToDo) BerniePope 07:07, 17 July 2006 (UTC) Notation. page 36. Section 12.1 Education. You write "embedded DSLs", earlier in Section 11.2 you use the acronym "DSEL" perhaps for the same thing?

BerniePope 07:14, 17 July 2006 (UTC) (SLPJ: done)Typo (possibly). page 36. Section 12.1.1 A survey of Haskell in Higher Education. On my screen it looks like there is an extra space after the number 28, in the sentence "Surprisingly, only 28 ..." Perhaps there is supposed to be a percent sign in there? Could be an artefact of the PDF viewer i'm using, but seems unlikely.

BerniePope 07:21, 17 July 2006 (UTC)(SLPJ: done) Typo. page 36. Section 12.1.1 A survey of Haskell in Higher Education. Bottom of second column. Backwards quotation marks at start of "The students who take the Haskell track ..."

BerniePope 07:56, 17 July 2006 (UTC) (SLPJ: done) Missing word. page 37. Section 12.2 Haskell and software productivity. "These contests have open to anyone." -> "These contests have been open to anyone."

BerniePope 08:03, 17 July 2006 (UTC) (SLPJ: done) Typo, page 37. Section 12.3. Darcs and Pugs. Third paragraph. "source coded" -> "source code".

BerniePope 08:25, 17 July 2006 (UTC) (SLPJ: done) Expression (minor). page 38. Section 12.4.2 Bluespec. "The purpose of them" -> "Their purpose". Later in the same paragraph there is a typo: "Haskell language construct" -> "Haskell language constructs" (plural).

(SLPJ: done) Typo on page 39: Another example is that Linspires toold must handle legacy data formats. --Neil Mitchell 15:23, 14 July 2006 (UTC)

Plareplane 01:13, 18 July 2006 (UTC)(SLPJ: done) Extra word. page 40. "given we the importance we usually attach"

ChristianSievers 20:12, 25 July 2006 (UTC) (SLPJ: done) Syntax. page 40, Python section: "In turn, Javascript another dynamically typed language...". There is a comma missing after "Javascript".

Josef 14:33, 4 August 2006 (UTC). (SLPJ: done) Typo. page 43. Reference to Duck, et.al. Should be "ESOP'04" instead of "ESPO'04".

Josef 14:33, 4 August 2006 (UTC). (SLPJ: done)Problem with swedish charaters. page 43. Reference to Dybjer. Should be "Martin-Löf's" instead of "Martin-Lf's". Use '\"o' in latex to get the umlaut.

(SLPJ: done)Typo on page 43: Missing letter in "Gdel". Phlucas 09:54, 17 July 2006 (UTC)

ChristianSievers 20:12, 25 July 2006 (UTC) Also wrong cases in the title. Both need some BibTeX magic.

(SLPJ: I think this is OK now) Two different papers are referenced as (Kiselyov et. al. 2004) in the text (bib entries on page 44). Phlucas 09:54, 17 July 2006 (UTC)

(SLPJ: done) Duplicate reference Wallace/Chitil/Brehm/Runciman on page 48. Phlucas 09:54, 17 July 2006 (UTC)

BerniePope 13:06, 16 July 2006 (UTC) (SLPJ:done) Overall. Capitalisation in headings seems to be inconsistent.

JaredUpdike 00:51, 18 July 2006 (UTC)(SLPJ: done) Many places, esp. sec. 12. The word "textbook" appears as "text book" and "text-book" although I believe "textbook" is the textbook spelling.

JevgeniKabanov 15:58, 18 July 2006 (UTC) (SLPJ: done)Page 25 has transactional mememory.

General comments

Section 1, 2, and 3

Josef 13:19, 4 August 2006 (UTC) I didn't find any reference to Haskell Prime. I think it is worth mentioning when, why and how the Haskell Prime effort was initiated.

(SLPJ: done, except I can't find a typeset Haskell 1.3 library report)ChristianSievers 20:12, 25 July 2006 (UTC) Page 5. You give the page count for some version of the report, but not all. At least for the first version, it should also be given, and why not just for all?

Padator 08:56, 17 July 2006 (UTC) Page 7. There is maybe too few discussions about the work of Stefan Kaes. I would like to know more about this topic.

(SLPJ: done) BerniePope 15:42, 15 July 2006 (UTC) Comment. page 7. Section 3.3, third paragraph. Rather than talk about "div" (are the first quote marks backwards?), perhaps you could say - "for example, Miranda's type system allows floating point values to be given to functions which are only defined on the integer subset of num, thus turning a static error into a dynamic one."

(SLPJ: done)Josef 13:14, 4 August 2006 (UTC) Comment. page 7. Section 3.4. Although Haskell doesn't have a formal semantics maybe it would be helful to point out that the report uses a core language which many features of Haskell are translated into.

(SLPJ: ToDo) sjthompson Sun Jul 23 16:47:55 BST 2006. Comment. page 8. Section 3.4 talks about 'equational reasoning' as being the basis of Haskell proof. It's a bit more complicated, since equational reasoning is limited to formalising the properties of equality as a congruence relation. To prove theorems about Haskell functions it's also necessary to use rules of induction which correspond to the recursive definitions of functions and data types. Induction suffices to prove results for the finite, fully defined, inhabitants of data types; variants of coinduction are needed to infer results over, for instance, infinite lists.

Section 4: Syntax

(SLPJ: ToDo) BerniePope 04:24, 18 July 2006 (UTC) Comment. page 9. Section 4 Syntax. I was a little surprised not to see a discussion of the literate style. Though it is not a Haskell invention, it still seems important.

(SLPJ: done)BerniePope 15:42, 15 July 2006 (UTC) Comment. page 10. Section 4.1, layout. It says "The rules are simple ...". I think this is a contentious issue. Recent discussions on the Haskell Prime mailing list [1] suggested a contrary view. How many Haskellers actually know the rules? Perhaps it would be more accurate to say that experience shows it is not hard to adopt a style of programming which stays within the rules.

(SLPJ: done)sjthompson Sun Jul 23 16:47:55 BST 2006. Comment. page 10. Section 4.1 I would agree with Bernie's comment, and would add that experience appears to show that layout of Haskell programs is more idiosyncratic than in other languages. There appears to be no widely accpeted layout style; and in the HaRe project (Li et al, 2003) ir was therefore necessary to preserve layout of user programs because it was unacceptable to users simply to pretty print programs in a standard layout.

(SLPJ: ToDo) BerniePope 15:42, 15 July 2006 (UTC) Comment. Footnote 2 on page 10 says the Scheme authors took a more Draconian approach with respect to operators, though it doesn't actually say what that means. On the off chance that someone reading the paper doesn't know Scheme, it might be worth elaborating on that point.

(SLPJ: it's still superficial compared, say, to type classes. But I agree that the full glory of pattern matching is far from trivial, although the Report does give a pretty detailed translation, including guards.)sjthompson Sun Jul 23 16:47:55 BST 2006. Comment. page 11. Section 4.4 "It is certainly true that the additional syntactic sugar makes the language seem more elaborate, but it is a superficial sort of complexity, easily explained by purely syntactic transformations." The differences are not purely syntactic, nor the transformations trivial. For example, it is possible to "fall through" from a guard to a subsequent equation, whereas if … then … else … provides an answer in every case. An closer equivalence would be forced by making a final "otherwise" clause mandatory.

(SLPJ: done)BerniePope 15:42, 15 July 2006 (UTC) Comment. page 12. Section 4.4. Near the end of the section you give an example of "where" being attached to a declaration. I think the example function "f" is rather obscure, perhaps there is a better example? Maybe one from the Prelude? Also, there seems to be another point you could make here. Due to laziness we get some more freedom in the way that we write where clauses. For instance, the thing being defined in the where clause may only be well defined in a subset of the alternatives. But that doesn't matter because we will only evaluate the thing if and when it is needed, not before.

(SLPJ: ToDo) BerniePope 15:42, 15 July 2006 (UTC) Comment. page 12. Section 4.5, list comprehensions. Perhaps it is worth noting the Haskell does not have the diagonalisation operator like Miranda. It may also be worth remarking on why this is so. Surely it was considered.

(SLPJ: done) sjthompson Sun Jul 23 16:47:55 BST 2006. Comment. page 12. Section 4.5. Erlang (strict) has list comprehensions.

(SLPJ: not sure this is worth it)Josef 13:33, 4 August 2006 (UTC) Comment. page 12. Section 4.5. I think parallel list comprehensions are worth mentioning. Although I don't quite know where. Maybe a new section called "Haskell as a syntax laboratory"?

Section 5 Data types

(SLPJ: not sure this is worth it.)ChristianSievers 20:12, 25 July 2006 (UTC) page 12 Section 5.1 discusses the empty type as sum of zero alternatives. While this is indeed not allowed by the syntax, we had Void. Maybe this should be mentioned somewhere.

(SLPJ: done) BerniePope 16:05, 15 July 2006 (UTC) Comment. page 13. Section 5.3 Abstract types. It says that the type has one constructor. Is it really necessary to limit the type to just one constructor? Surely it is enough that the constructors of the type are not exported, regardless of how many there are?

(SLPJ: done)ChristianSievers 20:12, 25 July 2006 (UTC) Page 13, section 5.3: The implementation of isempty results in an Eq a constraint on its type. Readers shouldn't be encouraged to test for empty lists in this way. Maybe also mention that because of different name spaces, the data definition could be data Stack a = Stack [a]. (SLPJ: for the latter, I just added an example in 4.3)

(SLPJ: done) Malcolm 10:44, 20 July 2006 (UTC) page 13. Section 5.3 Abstract types. I agree with Bernie's query above. It would seem that in Miranda, the abstract type must have only one constructor, but this restriction really does not apply in Haskell. Perhaps this is worth explaining in the text. Maybe if the description of Miranda's abstract types were placed before the Haskell version, it would be easier to make this point.

(SLPJ: too detailed?) ChristianSievers 20:12, 25 July 2006 (UTC) page 13f about n+k patterns. What about c*n patterns, was that only gofer? Maybe it could still be mentioned here.

Section 6 Type system

(SLPJ: Done, new section) BerniePope 13:24, 17 July 2006 (UTC) Comment. page 14. Section 6 Haskell as a type system laboratory. You don't seem to mention the defaulting rules of Haskell for unresolved numeric overloading. Whilst I think defaulting is somewhat of a wart, it is nonetheless of interest because it reveals some of the difficult design decisions that have to be made in the definition of a real programming language. Some of the most interesting parts of this paper are the sections which delve into the process of designing the features of Haskell, and maybe the defaulting story is worth telling too.

(SLPJ: done) BerniePope 05:28, 16 July 2006 (UTC) Comment. page 14. Section 6.1, Type classes. Perhaps it should mention that eqInt is primitive equality on integers, maybe as a comment in the code.

(SLPJ: added a whole para) Josef 13:40, 4 August 2006 (UTC). Comment. page 14-15. Section 6.1. You write 'A particularly attractive feature of type classes is that they can be translated into so-called "dictionary-passing style", by a typedirected transformation.' On the other side of the coin there is the problematic fact that type classes cannot be understood without some type directed translation. That might be worth mentioning. Together with the fact that dictionary translation isn't the only way to understand type classes.

(SLPJ: too detailed?) Josef 13:44, 4 August 2006 (UTC). page 15. Section 6.1. You mention the classes Read and Show. But up to Haskell 1.2 these were one class called Text. Worth mentioning perhaps?

(SLPJ: not sure what to do here, if anything) BerniePope 05:54, 16 July 2006 (UTC) Comment. page 15. Section 6.2 Monomorphism restriction. This marks one of the most unusual aspects of the language, especially in the Language Report. In particular, it is motivated by operational semantics --- sharing --- but the rest of the Report is largely silent on the issue. I think the Report says something to the effect of "programmers expect sharing to be preserved", but there is not much else in the Report to back this statement up. Perhaps you could tie this back to the discussion in Section 3.4 (Haskell has no formal semantics). Also, I think it would be reasonable to say "GHC provides a flag to suppress the restriction", without actually naming the flag.(SLPJ: mentioned this)

(SLPJ: hard to know what to say. The paper can't be a tutorial really.)BerniePope 06:02, 16 July 2006 (UTC) Comment. page 15. Section 6.2 Higher kinded polymorphism. It says "Here, the type variable m has kind *->*". It seems like the reader is already supposed to know what a kind is at this point. Perhaps the section could provide a little introduction to the concept of kinds first. Another thing about kinds is that they are sort of shadowy figures that seem to lurk in the background of Haskell. For instance they have no syntactic counterpart in Haskell 98. It can be quite daunting for beginners when they get a kind error.

(SLPJ: done) Malcolm 10:54, 20 July 2006 (UTC) Comment page 17. Section 6.6 Existential data constructors. Hbc, ghc, and Hugs have them. So does nhc98! So does jhc! In fact I'm not sure there are any compilers that don't support them.

(SLPJ: too detailed?) BerniePope 07:30, 16 July 2006 (UTC) Comment. page 17. Section 6.6 Implicit parameters. Perhaps contrast this approach to a Reader monad?

(SLPJ: too detailed; the reader will have to read the papers!)BerniePope 07:44, 16 July 2006 (UTC) Comment. page 18. Arrows. It doesn't really say what arrows are, except that they are like monads, but more general. Perhaps this could be elaborated, maybe with some mention of the intuition that arrows generalise things which are somehow composable? Perhaps an example of an arrow which cannot be done with a monad?

(SLPJ: arrows moved to 7.4) Josef 14:05, 4 August 2006 (UTC) page 18. Arrows. I think this discussion about arrows is misplaced. Arrows is not a type system thing. It's a library, perfectly implementable in Haskell98. Sure, there is some syntactic sugar that is desugared in the type checker in GHC. But there are other preprocessors for Arrows that doesn't need a type checker to work. I think Arrows should be mentioned somewhere in section 11 instead.

(SLPJ: done) Josef 14:05, 4 August 2006 (UTC) page 18. Generic Programming. I think PolyP is worth mentioning.

Section 7 Monads and IO

(SLPJ: reworded) BerniePope 08:14, 16 July 2006 (UTC) Comment. page 20. Section 7.2 Monads. It says that "Checking that the laws hold provides a reassuring sanity check when defining a new monad." Perhaps you could elaborate on exactly what we are checking, and subsequently reassured about. It says earlier that the laws show associativity and identity, but is there a more "programmer oriented" view of what this means?

(SLPJ: done)BerniePope 08:22, 16 July 2006 (UTC) Comment. page 20. Section 7.2 Monads. It says monads were helpful in structuring programs, including "the Haskell compiler itself". This sounds like there was a single Haskell compiler. Perhaps it should be "exisiting Haskell compilers"?

(SLPJ: done)BerniePope 08:22, 16 July 2006 (UTC) Comment. page 20. Section 7.2 Monads. One of the ongoing issues with monads is combining them together. Perhaps you could mention some of the attempts at doing this, such as monad transformers.

(SLPJ: done, somewhat briefly)JaredUpdike 23:16, 17 July 2006 (UTC) Comment. page 21. While reading and referring to the figures I keep getting confused by which Figure is Figure 2, Figure 3, etc. due to the heavy black lines which seem to act as separators, forcing my brain into believing that the heading applies to the code below the black line. Although I looked at the page as a whole to know which heading belongs to which figure, subconciously I am still confused by the dividing lines and automatically read the wrong heading for each section. Perhaps moving the lines, introducing a second set of lines above each section of code, or careful use of more whitespace (or complete boxes?) could alieviate or disambiguate these figures?

Section 8 Middle age

(SLPJ: reworded slightly) BerniePope 08:30, 19 July 2006 (UTC) Comment. page 24. Section 8.2.3 Summary. It says "a glance at the literature on ML modules will confirm" (regarding making things easier). Perhaps you could back this up with a sample of some references?

Section 9 Implementations

(SLPJ: done) Malcolm 10:59, 20 July 2006 (UTC) Correction. page 26. Section 9.4 - nhc. I did not collaborate with Niklas and Colin on the next-generation heap profiling tools. (Although I did implement profiling in Gofer, that was entirely separate from the next generation stuff.)

Sections 10 Profiling and debugging

BerniePope 13:04, 16 July 2006 (UTC) Comment. page 29. Section 10.3 Controlling Evaluation Order. The last paragraph suggests that we can wait until the program is written, then profile, then add seqs as necessary. While this is true, many programs are never really finished. Adding seq to code is one thing, but maintaining code with seq in it is another, perhaps more difficult problem. Also, you might be able to make a link here to the material on speculative evaluation, since that also solves some space/strictness issues.

(SLPJ: done) Robdockins 18:50, 19 July 2006 (UTC) In section 10.3 you mention that the presence of seq damages free theorems and the list deforestation in particular. You might want to mention the following paper, which deals with this issue: http://crab.rutgers.edu/~pjohann/popl04.pdf . Section 8.2 addresses list deforestation in particular.

(SLPJ: done) BerniePope 13:14, 16 July 2006 (UTC) Comment. page 29. Section 10.4 Debugging and tracing. It says that hbc and GHC provide trace. Hugs also has trace (perhaps nhc98 does as well?).

(SLPJ: done) Malcolm 11:07, 20 July 2006 (UTC) Re: trace, I can confirm that nhc98 has trace too.

(SLPJ: done) Malcolm 11:07, 20 July 2006 (UTC) Comment page 30. Section 10.4.1 Algorithmic debugging. Although Nilsson and Sparud's algorithmic debugger is no longer extant, Buddha is not the sole carrier of the flame. Sparud's later work led to Hat, which has included an algorithmic debugger (the hat-detect tool) since 2001.

BerniePope 04:59, 17 July 2006 (UTC) Comment. page 30. Section 10.4.2 Observational debugging. In the Hood library the type of observe is overloaded, like "observe :: Observeable a => String -> a -> a", which is both an interesting and useful application of type classes, and in some ways a limitation of hood, since it isn't polymorphic. I think it is important to point out the use of overloading here. Also, I think Hugs comes with a built-in polymorphic version, which of course isn't portable.

Section 11 Applications

(SLPJ: well, it's all in the monads chapter too, and I'm happy with that placement. I'm not sure what else we should say .) Josef 14:16, 4 August 2006 (UTC). page 31 section 11. I think that Monads and Arrows (M&A) deserve a special place here among your discussion about combinator libraries and DSELs. M&A are libraries for library writers, they provide support for deciding how to design a library and they implement a lot of useful code that can be shared among many libraries. Furthermore, the special syntaxes for M&A further help in creating DSELs. I think this form of libraries for libraries which M&A provide is rather unique to Haskell (although I could be wrong) and it is definitely worth a mention.

(SLPJ: done, replaced with RIFE) Hoan 12:45, 15 July 2006 (UTC) On page 33 it says that Ruby on Rails is a continuation based framework. I think thats wrong. PS. Its a riveting read.

(SLPJ: done) Malcolm 11:12, 20 July 2006 (UTC) Comment. page 34 Secion 11.2.4 Computer Music. The first mention of darcs (second para) seems to use it casually like everyone will know what it is. Perhaps a distinguished font (and a forward reference to 12.3?) might be appropriate.

(SLPJ: done)Malcolm 11:16, 20 July 2006 (UTC) Correction. page 35 Section 11.3 GUIs. The toolkit formerly known as "WxWindows" has been officially called "WxWidgets" for several years now (due to desire to avoid and trademark dispute with Microsoft).

(SLPJ: done) Josef 14:46, 4 August 2006 (UTC). Comment. page 35. Section 11.3. I find your current categorization and description of GUIs a bit misleading. As it is worded right now it misses out on the very strong connection between Fudgets and Fruit. These two libraries are extremely similar. But Fudgets ofcourse predates the invention of Arrows so it doesn't have that as a guiding principle. Maybe you should make a new bullet with Fruit and make a note about the similarities with Fudgets.

Josef 14:27, 4 August 2006 (UTC). Comment. page 35. Section 11.4 on Natural Language Processing. GF belongs in this section.

Section 12 Impact

(SLPJ: done) BerniePope 08:38, 17 July 2006 (UTC) Comment. page 37. Section 12.4 Companies using Haskell. Perhaps you could mention the Commerical users of FP workshop? Not limited to Haskell, but an important sign of a coming of age.

(SLPJ: done) BerniePope 13:29, 17 July 2006 (UTC) Comment page 39. Section 12.5 The Haskell community. Perhaps you could also mention the Haskell IRC channel [2], and some of its interesting software clients, especially lambdabot.

dons 06:37, 19 July 2006 (UTC) Out of interest, after seeing the mailing list graphs, I've prepared some similar analysis of the #haskell irc channel. It too shows similar growth patterns since 2001, when it was created. Details here

Simonpj 11:51, 19 July 2006 (UTC) Interesting data! I didn't know there were 2,000 users of the IRC channel. What does the time axis (labelled 1,2,3 ...) mean? 2001, 2002..? And why does the graph curve down at the end?

dons 14:15, 19 July 2006 (UTC) The x-axis are the years 2001-2006, (each point is for the previous year), and the graph curves down at the end as 2006-7 isn't finished yet. The 'X' floating above the end of the curve is where we project forwards to the end of the year. Note that we don't ever have 2,000 users concurrently (we averge around 200 users at a time). Over a year, however, 2,000 people (or unique names -- some are duplicates) will visit the channel.

(SLPJ: done. Actually it is the same use of "kind"!) BerniePope 08:22, 17 July 2006 (UTC) Comment. page 38. Section 12.4.2 Bluespec. It says "The type system has been extended with types of numeric kind." Perhaps this could be reworded to avoid the use of "kind", which has a specific meaning in types. Unless of course it does actually mean "kind" in the specific sense. Either way it could probably be clarified.

BerniePope 08:46, 17 July 2006 (UTC) Comment (not serious). page 39. Section 12.5 The Haskell community. It says that the Haskell Cafe' is most active in winters, with an amusing footnote about Scandinavia. Don't forget that in the southern hemisphere we have winter at the opposite time of the year! There are lots of Haskellers down here too! Also, if the winter connection is true, then it doesn't bode well for the adoption of Haskell in countries like Singapore and Indonesia.

Saccade 20:57, 17 July 2006 (UTC) Comment page 39 Section 12.5 The Haskell community. Footnote 14 is a lot more important than you seem to be giving it credit for. Polyglot programmers (like me) have a strong tendency to pick up new languages with great enthusiasm, and then ditch them a few years later with equally great enthusiasm. A reasonable null hypothesis model would be that about n_0 =~ 600 people get seriously into Haskell every year, and then have a roughly k =~ 4/5 chance of ditching the language for each year thereafter, giving n_t == n_0 * k^t serious users who have been using it for t years. This comes out looking a lot like your graph. (I'm not saying it's not possible that there's an explosion of interest, but this isn't very good evidence for it.)

(SLPJ: this section concentrates on similarities with Haskell (or contrasts in a closely related area) rather than being comprehensive. So I'm not sure what to add here that'd be brief but illuminating.) BerniePope 08:59, 17 July 2006 (UTC) Comment. page 40. Section 12.6. Influence on other languages. Maybe you can mention that Clean has a powerful system of dynamic types, and also generic functions which go beyond type classes. Also, since you mention that Clean has an I/O system based on linear types, you might also like to mention that Mercury also takes a similar approach, using unique modes.

(SLPJ: done) ChristianSievers 20:12, 25 July 2006 (UTC) Page 40. Python also has layout, propably this was also inspired by Haskell.

(SLPJ: done) ChristianSievers 20:12, 25 July 2006 (UTC) Page 40. And what about Cayenne?

Other notes

(SLPJ: done) BerniePope 09:08, 17 July 2006 (UTC) Comment. page 41. Section 13. Acknowledgements. In the last paragraph you note all the people who have contributed material, but you do not mention Nikhil, who is cited on page 38 as contributing the section on BlueSpec.

(SLPJ: done) Malcolm 10:50, 20 July 2006 (UTC) Re: Rishiyur Nikhil - he is mentioned in the acknowledgements. But I agree (below) that there is some inconsistency in naming him with family name only throughout the main text.

(SLPJ: done) BerniePope 12:15, 20 July 2006 (UTC) Rishiyur Nikhil is mentioned in the section about the Haskell committee, but he is not mentioned in the section about people who contributed to some sections, later on. Whereas Lennart and others are mentioned in both parts of the Acks.

(SLPJ: the intention is to use the first name on first occurrence. Pls do tell us where we missed that.) BerniePope 07:57, 16 July 2006 (UTC) Overall. Names of people. I've noticed that sometimes people are referred to by their whole name, whilst others are referred to by just their family name. Perhaps there is an underlying method here, but it wasn't clear to me. Perhaps it is that the first reference gets a full name, and subsequent ones are just the family name? Is that always the case?

(SLPJ: I fixed David H. (For ages I thought Lemmih was his real name!) Any others?) Malcolm 10:50, 20 July 2006 (UTC) Re: names. Just to add that the use of IRC nicknames in the text is a little disconcerting too. e.g. Lemmih (in real life: David Himmelstrup).

(SLPJ: ToDo) Abayley 07:37, 17 July 2006 (UTC) JHC gets a one-line mention - perhaps it deserves a little more? AFAICT, it was written by one person, as a student, who decided that the best way to learn Haskell was by writing a Haskell compiler. A commendable effort I think, and also a testament to the power of the language.

(SLPJ: ToDo) BerniePope 13:39, 17 July 2006 (UTC) Comment. Overall. The paper seems to be missing a conclusion at the end. Something to tie it all together. I was hoping to read a little bit about what the future of Haskell may bring - even though it would only be speculation, it would still be useful. What are the lessons learned? What would you do differently, now that you have the benefit of hindsight? Are we doomed to keep inventing programming languages? What does Haskell still need?

(SLPJ: there are lots of such papers, and we could easily cite a list, but it might look rather self-interested to do so.) AndrePang 00:45, 18 July 2006 (UTC) Comment. I'm not sure if this is appropriate for this paper, but perhaps a mention of significant papers to come out of GHC work would be good. The example I had in mind was pioneering garbage collection techniques, but there may also be other areas that are applicable. Even if it's a one or two paragraph blurb on it, it'd add to the impression that GHC is, in fact, a state-of-the-art compiler. For what it's worth, I also agree with Alistair Bayley about giving GHC more than a one-line blurb: it's an impressive piece of work with courageous goals.

(SLPJ: David doesn't want it.) JaredUpdike 00:49, 18 July 2006 (UTC) Question. Where is the standard "Miranda is a trademark of Research Ltd." disclaimer? Is it unnecessary given the fact that the history of Miranda is recounted and Turner given due credit?

(SLPJ: in progress) BerniePope 04:14, 18 July 2006 (UTC) Comment. Diagrams! I think a really useful addition to this paper would be a couple of diagrams. First, a timeline of the developments of Haskell. To help us put the whole thing in perspective. You could annotate the timeline with version numbers, interesting developments (like monads etc), major compiler/tool releases, significant events - in short all the stuff in the paper that was worth putting a date to. It would be a lot of work, but it would really help to draw the information out of the prose. Second, a kind of family tree of the languages mentioned in the paper. You see this thing from time to time on the net, but they never have all the little languages mentioned in this paper, like SASL, KRC, Orwell etc. I think that would be a useful contribution to programming language history in general. Again, a lot of work, but worth it in my opinion.

dons 06:44, 19 July 2006 (UTC) In response to Bernie's comment above regarding timeline, we almost have one. This page, extracted from the mailing list archives 1990-2006. It could possibly be used as a basis for some of the tool releases.

Simonpj 12:25, 20 July 2006 (UTC) A timeline diagram would be a great idea. Would anyone be interested in creating one for us, in exchange for a grateful acknowledgement in the body of the paper?

(SLPJ: quite right; done) Jmaessen 06:48, 20 July 2006 (UTC) Section 6.2: wasn't Bounded a later addition to Haskell (sometime 'round 1.3), rather than an immediate application of type classes? Or has my memory failed me?

Jmaessen 07:49, 20 July 2006 (UTC) Section 9.1 appears to be the first mention of views as a feature of Haskell 1.0. Surely this merits mention in one of the earlier historical sections?

ChristianSievers 20:12, 25 July 2006 (UTC) I think there should be some background about the name Haskell 98. At least that it was a community decision, maybe also a list of other suggestions.

davidk01 02:08, 29 July 2006 I finally get it, monads that is, and this paper is what put me over the edge. I think seeing it in a historical way is what did it, because I saw how a type constructor class is a natural generalization of regular type class.