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.
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).
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.
Typos, spelling, grammar, formatting and expression
BerniePope 15:42, 15 July 2006 (UTC) Typo: page 2, column 2, "Rod Bustall" should be "Rod Burstall".
BerniePope 15:42, 15 July 2006 (UTC) Spelling: page 3, column 1, "confernce".
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).
JaredUpdike 22:00, 14 July 2006 (UTC) 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)
BerniePope 15:42, 15 July 2006 (UTC) 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." ?
BerniePope 15:56, 15 July 2006 (UTC) 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" ?
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.
BerniePope 16:15, 15 July 2006 (UTC) 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) Typo. Section 5.6, page 14 and in Bibliography. Godel's name in citation missing the 'o'.
BerniePope 05:41, 16 July 2006 (UTC) Comment. page 15, column 1. "practical comprehensibility" is a bit of a mouthful. Perhaps "pragmatism" would suffice?
BerniePope 06:11, 16 July 2006 (UTC) 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) Typo, page 16. The code "n = (x + y)", perhaps drop the redundant parens?
BerniePope 07:19, 16 July 2006 (UTC) 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) 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) Typo. page 17. "patter-matching" -> "pattern-matching".
BerniePope 07:26, 16 July 2006 (UTC) Expression. page 17. Perhaps drop "rather than explicitly". This is implied by the previous "happens implicitly".
BerniePope 07:38, 16 July 2006 (UTC) Typo. 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]"?
BerniePope 08:39, 16 July 2006 (UTC) 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) Word missing. page 22. "So readFile a function that" => "So readFile is a function that".
JaredUpdike 04:27, 15 July 2006 (UTC) 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) 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) 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) 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) 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) Typo: page 31, column 2, "a central them" should be "a central theme".
BerniePope 05:47, 17 July 2006 (UTC) Typo. page 33. Section 11.2.1 Functional reactive programming. The instance declaration for Floating is missing "Behaviour a) where".
GaneshSittampalam 09:18, 15 July 2006 (UTC) Section 11.2.3 page 34 typo "unsagePerformIO".
BerniePope 06:44, 17 July 2006 (UTC) 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) 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) 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) page 35: "invariably based on a imperative widget" => "invariably based on an imperative widget".
BerniePope 06:54, 17 July 2006 (UTC) Typo. page 35. Section 11.4 Natural language processing. "Callaghan?s": there is a question mark where there ought to be an apostrophe.
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) 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) 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 ..."
Typo on page 39: Another example is that Linspire’s toold must handle legacy data formats. --Neil Mitchell 15:23, 14 July 2006 (UTC)
BerniePope 13:06, 16 July 2006 (UTC) Overall. Capitalisation in headings seems to be inconsistent.
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."
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  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.
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.
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.
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.
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?
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.
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.
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.
BerniePope 07:30, 16 July 2006 (UTC) Comment. page 17. Section 6.6 Implicit parameters. Perhaps contrast this approach to a Reader monad?
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?
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?
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"?
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.
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.
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?).
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.
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.
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?