- Haskell-prime - Haskell.org

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

Re: nubBy, groupBy specification
by Cale Gibbard 03 Jan '10

03 Jan '10

2010/1/2 <a.biurvOir4(a)asuhan.com>: > I'm inclined to agree with you. Could you please post the sources to both nubBy > and groupBy to see what has changed? > > Thanks, > Kim-Ee > yeoh(a)cs.wisc.edu Sure thing, Here is the report's implementation of nubBy: ------------------- nubBy :: (a -> a -> Bool) -> [a] -> [a] nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs) ------------------- And here is the implementation in GHC 6.10.4 and GHC 6.12.1: ------------------- nubBy eq l = nubBy' l [] where nubBy' [] _ = [] nubBy' (y:ys) xs | elem_by eq y xs = nubBy' ys xs | otherwise = y : nubBy' ys (y:xs) -- Not exported: -- Note that we keep the call to `eq` with arguments in the -- same order as in the reference implementation -- 'xs' is the list of things we've seen so far, -- 'y' is the potential new element elem_by :: (a -> a -> Bool) -> a -> [a] -> Bool elem_by _ _ [] = False elem_by eq y (x:xs) = y `eq` x || elem_by eq y xs ------------------- Note that the comment is actually incorrect. The report implementation of nubBy applies the function such that earlier accepted elements of the list are the left parameter to eq. Simply switching the y `eq` x to become x `eq` y in elem_by produces something which passes QuickCheck tests at the very least. I believe it's really the right thing at that point. The implementation of groupBy in 6.10.4 and 6.12.1 is the same as the report version, and I'm happy with it: ------------------- groupBy :: (a -> a -> Bool) -> [a] -> [[a]] groupBy _ [] = [] groupBy eq (x:xs) = (x:ys) : groupBy eq zs where (ys,zs) = span (eq x) xs ------------------- My main concern with it is that the report says: ------------------- When the "By" function replaces an Eq context by a binary predicate, the predicate is assumed to define an equivalence ------------------- which I think is much too strong an assumption given that these functions have reasonably natural and quite useful extensions to non-equivalence relations, which the code provided by the Report actually implements. - Cale

2 1

nubBy, groupBy specification
by Cale Gibbard 01 Jan '10

01 Jan '10

Hello, I've recently been irritated with (what I consider to be) broken versions of nubBy in GHC 6.10.4 and 6.12.1. For a while, groupBy was broken in the same way, but it seems to be fixed at least in 6.10.4. The problem is roughly caused by nubBy being specified only for symmetric relations, where this is actually a rather silly constraint, given that it captures a very common pattern of sieving (that at least I'd personally not want to have to write recursively every time). My most common usage of nubBy is actually probably nubBy (>=), (which has to be changed to nubBy (<=) for recent GHCs), and variations on it. This is extremely useful as a kind of lazier approximation of maximum or minimum. I occasionally use nubBy with equivalence relations (after these, I'd say (==) `on` foo is probably my next most common use case), but it's surprising how often that's actually not quite the right thing. Of course, there's also the inefficient but pretty example of constructing the list of primes using the divisibility relation and nubBy, which getting this wrong also breaks. What do people think of the following spec? nubBy f xs produces a subsequence ys of xs which satisfies: 1) f x y is False whenever x occurs before y in ys. 2) ys is maximal with respect to containment subject to condition 1. 3) The sequence of indices of selected elements is lexicographically minimal subject to conditions 1 and 2. (That is, the selections are made greedily.) Similarly, I think groupBy f xs should be specified as: groupBy f xs produces a list of lists yss of contiguous elements of xs such that: 1) concat yss = xs 2) Each element of yss is a nonempty list (y:ys) such that all (f y) ys. 3) The sequence of lengths of elements of ys is lexicographically maximal subject to conditions 1 and 2. (Again, this just means it greedily prefers to put elements in earlier lists rather than later ones.) Note that the code given in the Haskell 98 spec does the right thing with respect to these specifications, but Haskell 98 says that they're not specified for non-equivalence relations, while I think that they actually should be. A general policy that I think we should try to adopt is that the expression graph produced by a higher order function on lists, in terms of the supplied functions, should as far as reasonably possible maintain the left-to-right order of occurrences of elements as they occurred in the list. This makes the precise behaviour easy to remember, and tends to keep expression graphs easy to draw. foldr, foldl, scanr, scanl, mapAccumL, nubBy and groupBy (as specified above), all follow this rule (of course, many simpler HOFs do as well). mapAccumR as specified strangely does not, which makes it another thing I'd like to change. (See: http://cale.yi.org/index.php/Fold_Diagrams) cheers! - Cale

1 0

Nominations for the Haskell 2011 committee
by Simon Marlow 30 Dec '09

30 Dec '09

So that the Haskell 2011 cycle can get underway, we are soliciting nominations for new committee members. Since this is the first time we've done this, the procedure is still somewhat unsettled and things may yet change, but the current guidelines are written down here: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee In particular, on the makeup of the commitee: The committee should represent each class of stakeholders with roughly equal weight. These classes are * Implementers (compiler/tool writers) * Commercial users * Non-commercial users (e.g. open source) * Academic users (using Haskell in research) * Teachers * Authors In addition, members of the committee should be long-standing users with a deep knowledge of Haskell, and preferably with experience of language design. The committee should contain at least some members with a comprehensive knowledge of the dark corners of the Haskell language design, who can offer perspective and rationale for existing choices and comment on the ramifications of making different choices. To nominate someone (which may be yourself), send a message to haskell-prime(a)haskell.org. Please give reasons for your nomination. The current committee will appoint new commitee members and editors starting in the new year, so the deadline for nominations is 31 December 2009. During discussion amongst the current commitee, we realised that the choice of committee should be informed not just by the criteria above, but also by the particular proposals that are expected to be under consideration during this cycle. With that in mind, we plan that following the nominations the current committee will choose a "core commitee" of up to 10 members, and further members may be appointed during the year based on expertise needed to consider particular proposals. Accordingly, now would be a good time to start discussing which proposals should be considered in the Haskell 2011 timeframe, as that may affect the choice of commitee members. More details on the current Haskell Prime process are here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Cheers, Simon

4 4

nomination for Haskell 2011
by S. Doaitse Swierstra 23 Dec '09

23 Dec '09

Herewith I propose Atze Dijkstra as a member of the Haskell 2011 committee. Atze is the main architect/implementor of the Utrecht Haskell Compiler (see http://www.cs.uu.nl/wiki/UHC, and last year Haskell Symposium), and has as a result of that a very good insight in the implementation issues involved with new features/extensions/changes. He furthermore co-supervises Arie Middelkoop who is working on the Ruler system, which aims to be a tool for describing (the implementations of) type systems, and Jeroen Fokker who is working on a Grin-based whole- program analysis The compiler itself is currently about 100.000 lines of Haskell. A second release is planned for the beginning of next year, which will contain a completely new garbage collector, a cabal based installation scheme, and the beginning of some global optimisations. I think Atze primarily covers the following categories: Implementors, Academic users, Teachers. If you have any questions I am more than willing to answer them, Doaitse

1 0

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 29 Nov '09

29 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