January 2006 - Haskell-prime

what's the goal of haskell-prime?
by Johannes Waldmann 12 Feb '06

12 Feb '06

Dear all, in the "mission statement" I read > We will strive to only include tried-and-true language features, but the current discussion seems to have a wider focus, i. e. it is more of a wish list. Indeed I think that this is a good idea (ask (future) Haskell users what they want) but it might not be the original goal of the Haskell-Prime effort. On the other hand, design-by-committee (or by wiki, call it what you want) has its problems. Just for our enjoyment, here are two quotes from Stroustrup: Design and Evolution of C++ (1994) (ch. 12.6, p. 269f): * ... Tom Cargill got a lot of applause for the .. suggestion that anyone who proposed a new feature for C++ should also propose an old feature of similar complexity that should be removed... * Jim Waldo .. followed up with a further idea: Proposers of new features should be required to donate a kidney. That would make people think hard before proposing, and even people without any sense would propose at most two extensions. I like to stress that when discussing an extension, we should strive to clearly state the problem that it tries to solve, and we should check carefully what solutions are already known (within Haskell, or within other languages/libraries). Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

8 10

Comment Syntax
by Thomas Davie 11 Feb '06

11 Feb '06

I would like to suggest a different change to single line comment syntax to do two things. First, address an inconsistency with multi line comments, and secondly remove one of the main sources of confusion for beginners. My proposal is to make any text beginning '--' a comment (rather than requiring a space after the two dashes. I appreciate that the argument against this is that various operators that look like this are useful (e.g. -->). However I think that any benefit gained by operators like this is lost in confusion. In order to back up my suggestion, I'd like to point out, that this is indeed already how it is done for block comments. i.e. we do not expect {-> to be an operator, we expect it to be the beginning of a comment. Secondly, from my limited experience helping to teach Haskell, the comment syntax is a primary source of confusion for beginners. Beginners inevitably forget (or don't know) to add the space, and will receive confusing errors about undefined symbols, or type mismatches. This is made yet more confusing by the fact that the compiler appears to be pointing at an error in a comment. Thanks Tom Davie

18 40

RE: ~ patterns
by Simon Marlow 10 Feb '06

10 Feb '06

On 30 January 2006 12:32, John Hughes wrote: > I don't really agree that ~ adds complexity to the language design, > given that we need > SOME mechanism for lazy pattern matching. If you write > a denotational semantics of pattern matching, then ~ fits in > naturally. It has a simple, > compositional semantics. Where I see complexity is that a pattern > means different > things in a let or in a case, so I have to remember, for each > construct, whether it's > a strict-matching or lazy-matching construct. Quick, when I write do > (x,y)<-e... > is that pair matched strictly, like case, or lazily, like let? If > strictly, then why? There's > no choice to be made here, so why not wait until x or y is used before > matching? I expect > you know the answer to this question off-hand, but it's an obstacle to > learning the > language--I'll bet there are many quite experienced Haskell > programmers who are > uncertain. If only pattern matching was *always* strict, unless a ~ > appeared, then the > language would be more regular and easier to learn. For what it's worth, I agree with this point. I'd be quite happy for pattern matching to be strict by default in let and where. I can imagine it might still be confusing to some, though, because let x = fac 99 does not evaluate 'fac 99', but let (x,y) = quotRem a b does evaluate 'quotRem a b'. Still, I suppose it's no more confusing than the current situation. If pattern matching in where was strict, I imagine I'd use ~ a lot more. A common practice is to throw a bunch of bindings into a where clause, with no regard for whether they get evaluated or not - variable bindings and pattern bindings alike. If the pattern bindings are strict, I have to add ~ to each one to get the same effect. On the other hand, if pattern bindings were strict by default, I bet there would be a lot fewer accidental space leaks. Cheers, Simon

11 14

Existential types: want better syntactic support (autoboxing?)
by Johannes Waldmann 06 Feb '06

06 Feb '06

It is standard practice to hide implementation details, in particular, not publishing the type of an object, but just the interfaces that its type implements. We can do this with existential types but the notation feels clumsy. See my message http://www.haskell.org//pipermail/haskell-cafe/2005-June/010516.html -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

11 20

The dreaded M-R
by John Hughes 04 Feb '06

04 Feb '06

I had promised myself not to propose anything that was not already implemented, tried, and tested, but I just can't resist bringing up a proposal I've made in the past to fix the monomorphism restriction. Maybe now is the time to do so. I know many will proclaim "just get rid of it", but consider this: without the M-R, some programs can run exponentially slower than you expect. This actually happened to me, which is how we discovered something of the sort was needed in the first place. But the current design is surely a wart. The fact is, Haskell has two different binding mechanisms--bind-by-name (used for overloaded definitions), and bind-by-need (monomorphic). Both are useful: bind-by-name lets us name overloaded expressions, while bind-by-need gives performance guarantees. The trouble is just the way we distinguish them--where the compiler is basically guessing from the form of a definition which one to use. Two problems that leads to: * You can't eta-convert definitions freely, if there is no type signature. We've all hit this one, where you write something like sum=foldr(+)0 and you can't export it, because it's monomorphic. * Definitions without a type-signature can change from polymorphic to monomorphic as a result of changes elsewhere in the program. Because the M-R applies only to overloaded definitions, then introducing, for example, an equality test in a function the definition calls can change its type, and make the M-R suddenly apply where it did not before. That can lead to unexpected errors. The solution I favour is simply to use *different syntax* for the two forms of binding, so that a definition is monomorphic, and computed at most once, if it uses the monomorphic binding operator, and polymorphic/overloaded, computed at each use, if it uses the other. Whether it's a function definition or not is irrelevant, as is whether or not it carries a type signature. The trick is finding good syntax. I suggest = for bind-by-name, and := for bind-by-need. (Some object that := "means" assignment--but come on, we're not reserving := for future use as assignment in Haskell, are we? Why should we give up a perfectly good symbol because it's used elsewhere to mean something else?). With this notation, = would be appropriate for function definitions, and := for most non-function definitions. It would be instantly clear where there was a possibility of repeated evaluation, and where not. The problem with making such a syntactic distinction is that, however it's done, many changes must be made to existing programs. Just because existing programs contain many bindings of each sort, there's no getting away from the fact that a syntactic distinction will force changes. In principle this could be automated, of course--not hard but somebody would have to do it. But perhaps it would be worth it, to eliminate probably the number one wart, and solve the problems above. I put it on the table, anyway. John

12 22

separate class and type namespace
by John Meacham 04 Feb '06

04 Feb '06

What do people think about seperating the class and type namespaces? one can always tell the difference syntactically which is meant, the only thing keeping them in the same space in jhc is an artificial check to ensure you don't create some of the same name. the only issue is in export/import lists if you wanted to allow import/export of the type independently of the class. however the proposed explicit namespace change to the import/export syntax would solve this too and it is unlikely to actually be a problem in practice. this would allow things like one to have a class and a data type holding an arbitrary member of said class to have the same name. it is unwieldy to have things like FooClass and Foo be separate. John -- John Meacham - ⑆repetae.net⑆john⑈

8 14

RE: The dreaded M-R
by Simon Marlow 03 Feb '06

03 Feb '06

I've put a wiki page with a summary of this discussion here: http://hackage.haskell.org/cgi-bin/haskell-prime/trac.cgi/wiki/Monomorph ismRestriction Hopefully I've captured most of the important points, please let me know if there's anything I missed, or misrepresented. I'll add a ticket shortly. Given the new evidence that it's actually rather hard to demonstrate any performance loss in the absence of the M-R with GHC, I'm attracted to the option of removing it in favour of a warning. Cheers, Simon

14 18

RE: ~ patterns
by Simon Marlow 03 Feb '06

03 Feb '06

On 30 January 2006 18:20, Isaac Jones wrote: > Can someone be sure to capture the pros, cons, and relationship to the > !-patterns proposal as a ticket / wiki page? I've been swayed by the arguments put forward by the ~-proponents, so I'm not going to champion the removal of ~ any more. We must find *something* to throw away though! :-) Cheers, Simon

17 28

RE: separate class and type namespace
by Simon Marlow 02 Feb '06

02 Feb '06

On 31 January 2006 03:42, John Meacham wrote: > What do people think about seperating the class and type namespaces? > one can always tell the difference syntactically which is meant, the > only > thing keeping them in the same space in jhc is an artificial check to > ensure you don't create some of the same name. > > the only issue is in export/import lists if you wanted to allow > import/export of the type independently of the class. however the > proposed explicit namespace change to the import/export syntax would > solve this too and it is unlikely to actually be a problem in > practice. I've always liked the idea of saying 'class C' or 'type T' in import/export lists. It could be made backwards compatible: we allow types and classes to be named the same, but in this case the export list has to use the new syntax to disambiguate. The idea would be to transition to the new syntax eventually. There's a choice about whether a newtype should be exported with 'newtype T' or 'data T', or either. Cheers, Simon

8 7

Wanted: local data, class, instance declarations
by Johannes Waldmann 02 Feb '06

02 Feb '06

in today's Haskell, all data and instance declarations are global, which sometimes leads to violations of the information hiding principle. E. g. if there is a function sort :: Ord a => [a] -> [a], and I want to sort a list of items w.r.t. a specified ordering, then I would want to write let instance Ord Item where ... xs :: [ Item ] ; xs = ... in sort xs but I don't want to make the instance Ord Item global because I might need a different instance in another place, or there already is a global instance but I don't want it. So, the local instance should override an outer or global one. Shouldn't be too difficult, the compiler just has to insert the proper dictionary (the "most local" one that's visible at the call site). With current all-global instances, a sort function of the given type is not very flexible, leading to supplementary functions (sortBy), see "Generalized functions" e. g. in http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#22 This is exactly a work-around for not being able to make local dictionaries, right? Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

4 5