November 2009 - Haskell-prime

Unsafe hGetContents
by Florian Weimer 23 Jan '10

23 Jan '10

Are there any plans to get rid of hGetContents and the semi-closed handle state for Haskell Prime? (I call hGetContents unsafe because it adds side effects to pattern matching, stricly speaking invalidating most of the transformations which are expected to be valid in a pure language.)

5 15

export keyword
by Аркадий Рост 07 Dec '09

07 Dec '09

What about using export keyword to mark the exporting functions?

2 1

On the Meaning of Haskell 7
by John D. Earle 30 Nov '09

30 Nov '09

This may be the last in the series given that Simon Marlow feels that I am being non-sequitur. I on the other hand feel that I am being very much on topic. To quote Dune, "They move in mysterious ways." I wanted to complete a thought and I thought to end it on number 7. My guess is why the case-of construct is preferred is due to Haskell being a functional language. In other words the world is to be wrapped up into a ball and passed like a basketball. The if-then-else paradigm holds a world view where the world consists of disparate parts to be accessed and tested, however. This supports my thesis. It may be worth considering the removal of if-then-else as opposed to fixing it. Simon Marlow wrote "haskell-prime(a)haskell.org is specifically for discussing proposals for changes in future revisions of the Haskell language." I have an anti-proposal. Do not change anything unless you know what you are doing. Don't make a proposal unless you know what you are saying.

2 1

On the Meaning of Haskell 6
by John D. Earle 30 Nov '09

30 Nov '09

I have used the expression Forefathers of Haskell before. Someone earlier wrote "Haskell will die with the two Simons." Cruel words that perhaps were not meant to be cruel per se, just a perceived fact. Making the ancient sign with my hand that signifies my authority as a teacher my response is as follows: One must master logic, but not be its slave. In so many ways it is true, from dust to dust; but any earnest entreaty upon this hallowed ground would involve a token of respect such as this. We are fortunate that we have him. Let us not be neglectful for what we have while we still have it! In retrospect poor Simon may have said to himself, "What! I'm not dead and buried yet! What is this man saying! I'm not that old!" Perhaps I have caused him to chuckle privately. I would prefer the later.

2 1

On the Meaning of Haskell 5
by John D. Earle 30 Nov '09

30 Nov '09

I was going through my library and while scanning through everything something germane caught my eye. It was from something that Stephen Gilmore of The University of Edinburgh wrote, namely "Programming in Standard ML '97: A Tutorial Introduction". A copy can be gotten from the Moscow ML home page. I feel that he put the matter well. In section 1.2 he writes: "It is ... perfectly easy to imagine users finding fault with a correct program which has some missing functionality which they would like." With this there is also a temptation to screw things up if you have the power to do so. If may feel democratic, but you won't really be doing anyone a favor. There is a need to reserve judgment until a comprehensive understanding and appreciation of the language is achieved. For example, I find it curious that if-then-else constructs are defined in terms of case-of and not the other way around. This is conspicuous and so there may be good cause for why it was done this way. I chose to err on the possibility that the Forefathers of Haskell knew what they were doing and it is just that I do not yet fully understand the why. The if-then-else construct as it is defined in other languages is more general than case-of. It appears that in Haskell the if-then-else construct though a prominent feature of many languages has no real significance as Haskell is concerned and is there solely for convenience. Rather than molesting Haskell to make nice to those whose delicate sensibilities are offended by how the if-then-else construct has been formulated it may be best to remove the if-then-else construct from the language altogether since it appears that the if-then-else construct was an ad-hoc addition or is a vestigial appendage that serves only to confuse the reader.

1 0

On the Meaning of Haskell 4
by John D. Earle 28 Nov '09

28 Nov '09

Experimental languages are intended to prove a point. "Agda or Epigram or Coq" and the like are experimental as well so it seems moot to say they are the future. The question is, Is Haskell a solid foundation to build upon? The Haskell language has been brave and perhaps too brave. Everyone knew that layout could get you into trouble and so most everyone had the good sense to avoided it. With Haskell it made sense due to its emphasis on white space. In typography white space is crucial. It is helpful to clear away the clutter that fogs the mind. When it is beautiful it is easier to read. It becomes a pleasure to read. I take no issue with the two Simons for being uncompromising. This is to be admired. As layout is concerned though it was risky, I'm not ready to give up on layout. Apart from those who state objection to Haskell in that it does not behave like C. Since the paradigms are different one could expect that how things are done are different. So I'm throwing that out and them out with it. It is not a cogent criticism. There are still things that can be done, but it involves breaking with backward compatibility and doing it right this time. Near perfection is possible. You just have to want it bad enough. It is funny that you should speak of the Coq proof assistant and related projects. You don't get it do you? It isn't about kind of getting it right. It is about having a formal mathematical proof that you got it right. I'm uncertain if Haskell in its present state can deliver. With all this monkeying with the language and ad-hoc changes it won't improve things. It will just be business as usual. Though Epigram is written in Haskell I don't see it going anywhere. Coq is not written in Haskell. Most proof assistants worth their salt aren't. I think I now understand why. Haskell has a grocery list of proof assistant projects that either were abandoned or look like they were abandoned. I don't think that should be, but maybe I'm just in the minority. If you think "Agda or Epigram or Coq" is the future, why then do you hold such thoughts as "We shouldn't try too hard to get Haskell right". It doesn't follow logically. Someone has got to get it right for Epigram, et al, to get it right.

1 0

On the Meaning of Haskell 3
by John D. Earle 28 Nov '09

28 Nov '09

I believe Simon got right what he got right, but nothing more. Haskell is an experimental language that is taking off prematurely. In my opinion it needs to be taken back to the drawing boards and overhauled before it is too late. It may already be too late unfortunately. We may have to live with whatever mistakes that were made for the next 100 years. Sometimes success is not a good thing. Haskell can easily become yet another defective language. Backward compatibility will likely need to be thrown out the door if Haskell is to ever stand for the "truth". Greater rigor in getting it right is needed.

2 1

Re: DoAndIfThenElse
by Christian Maeder 27 Nov '09

27 Nov '09

S. Doaitse Swierstra schrieb: [..] >> \begin{code} >> main = do >> if True then putStrLn "1"; >> else putStrLn "2" >> \end{code} >> >> This does also not work with hugs (";" at the end) > > This does not work since now you have two ";"'s; one because you wrote > one and one because you did not indent the else. Allowing this > additional ; was done to prevent confusion, and as you can see even more > confusion pops up now;-{{ That is why I expressed my concerns about this > grammar patch. > > Doaitse Indeed, these semicolons are confusing. I think it should be possible to allow "then" and "else" starting in the same column as "if" without these ";"s (in a do block). Christian

3 3

DoAndIfThenElse
by Christian Maeder 26 Nov '09

26 Nov '09

Hi, seeing Haskell 2010 and http://hackage.haskell.org/trac/haskell-prime/wiki/DoAndIfThenElse saying: Compiler support ¶ GHC full (no flag) I wonder why I still get a "parse error (possibly incorrect indentation)" for: \begin{code} main = do if True then putStrLn "1" else putStrLn "2" \end{code} Can I try out this feature somehow? Cheers Christian

3 5