February 2006 - Haskell-prime

RE: Priorities
by Simon Marlow 06 Feb '06

06 Feb '06

On 05 February 2006 00:21, Benjamin Franksen wrote: > On Friday 03 February 2006 08:52, Tomasz Zielonka wrote: >> On Thu, Feb 02, 2006 at 01:05:57PM +0000, Ross Paterson wrote: >>> Personally, I'm not sure about caseless underscore, concurrency, >>> natural numbers and parallel list comprehensions. >> >> There is one more reason to leave concurrency out of the standard. >> >> Some experts (like Hans Boehm) argue, that concurrency can't be >> added to the language as a library. >> http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf >> >> This is true for many imperative programming languages. Haskell >> seems to be an exception: >> >> http://www.haskell.org//pipermail/glasgow-haskell-users/2005-December >> /009417.html >> >> We don't have any problems with ensuring good cooperation between >> mutable variables and concurrency synchronisation primitives, because >> the language doesn't have mutable variables, they are delivered in >> the concurrency library - the variables _are_ the synchronisation >> primitives. > > What about IORefs? The interaction between concurrency and IORefs was recently discussed on the ghc-users list: http://www.haskell.org//pipermail/glasgow-haskell-users/2005-December/00 9389.html Cheers, Simon

1 0

Re[2]: [Haskell-cafe] Why is $ right associative instead of left associative?
by Bulat Ziganshin 06 Feb '06

06 Feb '06

Hello Henning, Monday, February 06, 2006, 4:12:44 PM, you wrote: >> In my opinion all the special syntactic sugar for lists should go >> away. I don't think lists are special enough to motivate it. HT> Fine, someone shares my attitude towards the list sugar. Nevertheless, do HT> you mean with 'no sugar for lists' also no infix operator for list HT> construction? I would still like an operator of low precedence for list HT> construction for writing e.g. (1,'a"):(2,'b'):[]. i prefer to have ":" and "[]" as general collection constructors: class Collection c a where [] :: c a -- creates empty collection (:) :: a -> c a -> c a -- adds value to the head of collection and having "default rules" that instatiates this collection type to list if there is no type signatures and other information what allows to find proper type of collection constructed this way - just like the "default Int" language construct defaults all untyped numeric constants to Int -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

FilePath as ADT
by Axel Simon 06 Feb '06

06 Feb '06

I think this is not yet discussed on the wiki: >From the recent post to the Haskell list: -------- Forwarded Message -------- From: Krasimir Angelov <kr.angelov(a)gmail.com> To: haskell <haskell(a)haskell.org> Subject: [Haskell] System.FilePath survey [..] * Will you be happy with a library that represents the file path as String? The opposite is to use ADT for it. The disadvantage is that with the current IO library we should convert from ADT to String and back again each time when we have to do any IO. The ADT may have advantages for the internal library implementation. [..] Cheers, Krasimir _______________________________________________ The chance to change the libraries is a chance to get the FilePath type right. We had a thorough discussion on this already, I think there was a silent consensus that the FilePath must be an abstract data type due to Unicode reasons. The discussion back then evolved around the following: The task: Remove all files in a directory recursively. The problem: In case the current encoding is UTF-8, filenames stored in a different locale can comprise illegal UTF-8 sequences and are therefore not representable as FilePath which is a Unicode string. Even if the resulting Unicode sting is not 'error ".."', it is impossible to call 'delete' on that file name, since fromUTF8 . toUTF8 cannot be the identity function if the UTF8 byte sequence is illegal. The solution: FilePath must be an abstract data type that is a sequence of bytes. Programmers should only convert these to Unicode for displaying them and otherwise treat them as opaque entities. In case of invalid UTF-8 strings, the corresponding String will have an "invalid unicode code character" substituted. The solution of representing a file name abstractly is also used by the Java libraries. Are there any objections to changing this? Axel.

5 7

Type Class Directives
by Jim Apple 06 Feb '06

06 Feb '06

Would we consider type class directives, as in: http://www.cs.uu.nl/~bastiaan/padl05-heeren-slides.pdf http://www.cs.uu.nl/~bastiaan/hh05classdirs.pdf The idea is that there are some modifiers to class declarations: never close disjoint default I assume the committee knows these better than I, but a short summary for those who haven't sen these before is that: never adds prevention of particular absurdities: never Eq (a ->b) close restricts classes to particular areas: close Integral (Int, Integer) disjoint (Integral, Fractional) and defaulting is discussed http://hackage.haskell.org/trac/haskell-prime/ticket/21 Jim

2 1

RE: Representing Tuple types as products
by Simon Peyton-Jones 06 Feb '06

06 Feb '06

| Currently in GHC, we have the problem that it seems impossible to put | unicode characters in source files at all, even in string literals. Actually Simon added Unicode support to GHC a few weeks ago, so source files can now use Unicode characters. Try any HEAD build or binary snapshot. Simon

1 0

Priorities
by John Hughes 06 Feb '06

06 Feb '06

For the last few days, my mail-box has been full of mail about the M-R, lazy pattern matching, n+k patterns, comment syntax--it's just like the good old days! And that worries me. Each of these topics is a snake pit--a tricky area of language design, with many alternative possibilities and no clear winner. As such, they make great discussion topics--if you want to start a heated argument, just propose a change to one of these (mea culpa)! We've also been discussing most of them for sixteen years. Of course, it's worth raising them from time to time, in case new insight means we can find a solution that is clearly much better than we found before. But the risk is that we go over the same old arguments, perhaps the consensus is slightly different this time, we make a change to the language, and who knows, next time the language is revised, maybe it'll change back again! That's destructive. We shouldn't change these things unless we can very, very clearly make an improvement. The fact is, we've lived with the present design for over a decade in each case, and we can live with it for another decade if we have to. The problem with Haskell 98 is not its warts--it offers a very pleasant programming experience despite them. The problem with Haskell 98 is that it *lacks* features which have become absolutely essential to Haskell programmers today. Those features are what really *need* discussion and energy spent on them. What are the top priorities for inclusion in a new standard? How can we identify them? I have some personal favourites, of course: ST state threads--absolutely essential. - but how to distinguish strict and lazy state? The present solution--importing a different module--sucks. Monad transformers - dramatically simplify constructing new monads - not a language feature in themselves, but demand extensions to work well. Multi-parameter classes with functional dependencies - used everywhere... for example in monad transformers... so *must* be included this time - omitted from Haskell 98 because "the right design" wasn't clear - it's still unclear! Functional dependencies *in some form* are essential, but associated types and datatypes look nicer in many ways! - is it too late, in practice, to replace fundeps by something else? How will we know? If we are to standardize on associated types instead, we need a major effort to *make sure* all important applications of fundeps can be represented. How will we organize that? Type system extensions--at least existential and rank-2 types. - should we go further? How will we know? My favourites may not be your favourites. How will we know what the most important features to discuss are? Here's a thought: Wouldn't it be nice if the most important Haskell tools and libraries, were actually written in standard-compliant Haskell'? One such tool is wxHaskell--named by 19% of Haskell users in my survey, it's the de facto standard GUI toolkit. wxHaskell makes essential use of existential types in its interface, a strong reason for including them in Haskell'. It also uses multi-parameter classes and functional dependencies, although much less heavily. What other tools "must" be supported by Haskell'? What other extensions must be present to support them? What issues remain before those extensions are standardized, and thus frozen in stone for many years to come? I'd like to see clearer priorities and a more focussed discussion--maybe the Wiki can be used to help? John

12 20

[Fwd: Re: Haskell-prime Digest, Vol 2, Issue 6]
by Henrik Nilsson 05 Feb '06

05 Feb '06

Hmm. Seems I missed sending this to haskell-prime. Sorry. /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn(a)cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

2 1

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

05 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

objective data on use of extensions
by Isaac Jones 04 Feb '06

04 Feb '06

I would like to strive to find objective data on the use of extensions. I started a table here which summarizes how popular extensions are in real-life code. We need more data points, though. http://hackage.haskell.org/trac/haskell-prime/wiki/ExtensionsExperiment I have a short program which queries the hackage database, gets some details about all of the packages there, and summarizes them into a table. Right now, there really aren't that many packages on HackageDB, but hopefully more will appear. HackageDB is here: http://hackage.haskell.org/ModHackage/Hackage.hs?action=home You can upload packages with Cabal-Put, but it's pretty hackish right now. I put detailed installation instructions on the wiki: http://hackage.haskell.org/trac/hackage/wiki/CabalPut A list of cabal packages that might be good for uploading is here: http://hackage.haskell.org/trac/hackage/wiki/CabalPackages The more packages we get into HackageDB, the more accurate objective data we can build. Let me know if you want to help! peace, isaac

2 2

Re: [Haskell-cafe] Re[2]: strict Haskell dialect
by Jan-Willem Maessen 04 Feb '06

04 Feb '06

On Feb 3, 2006, at 8:16 PM, Brian Hulley wrote: > Jan-Willem Maessen wrote: > >> I pointed out some problems with strict Haskell in a recent talk, but >> I think it'd be worth underscoring them here in this forum. > > Is the text of this talk or points raised in it available online > anywhere? > >> <snip> There is one very difficult piece of syntax in a strict >> setting: The >> *where* clause. The problem is that it's natural to write a bunch of >> bindings in a where clause which only scope over a few conditional >> clauses. I'm talking about stuff like this: >> >> f x >> | p x = ..... a ...a . a .... a ... >> | complex_condition = ......... b .. b ... b ...... >> | otherwise = ..... a ....... b ..... >> where a = horrible expression in x which is bottom when >> complex_condition is true. >> b = nasty expression in x which doesn't terminate when p x >> is true. >> complex_condition = big expression which >> goes on for lines and lines >> and would drive the reader >> insane if it occurred in line. > > Surely it would not be too difficult for the compiler to only > evaluate the where bindings that are relevant depending on which > guard evaluates to True ie in your example, the binding for a would > be evaluated if p x is True, otherwise the complex_condition would > be evaluated, and if True, b would be evaluated, otherwise a and b > would be evaluated: ... In principle, yes, this is eminently doable. But the translation becomes surprisingly messy when the bindings in question are mutually recursive. Certainly it's not a simple syntax-directed translation, in contrast to essentially every other piece of syntactic sugar in the language. -Jan-Willem Maessen

1 0