February 2006 - Haskell-prime

Strict foldl
by Marcin 'Qrczak' Kowalczyk 15 Feb '06

15 Feb '06

Haskell standard should get a strict foldl: either under some new standard name (foldl' is most common), or just replacing foldl. Is there a real-life case where a lazy foldl is desirable? I don't mean a constructed artificial example, I know they exist, but something which is really used. Currently usages of foldl fall into two major groups: those which are inlined and transformed into a strict foldl by an optimizing compiler, and those which have a space leak and a potential for stack overflow for large data. Even if there are cases where a lazy foldl is essential, I would prefer to have to code them with an explicit recursion, and reserve foldl for the more common cases where it should better be strict. -- __("< Marcin Kowalczyk \__/ qrczak(a)knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

2 1

RE: First class labels
by Simon Peyton-Jones 14 Feb '06

14 Feb '06

| the concrete proposal is to address one of these remaining issues, | namely how to identify record field labels as such. for that, I outlined | three options, although that outline perhaps wasn't concrete enough: | | 1. make label declarations unneccessary (eg., #pointX :: #PointX) | | 2. make type sharing expressible (something like the sharing | constraints in Standard ML's module language, to allow you to | say when two declarations from different imports refer to the | same type) | | 3. introduce a least upper bound for shared label imports | (so A and B could just 'import Data.Label(pointX)', which | would magically provide the shared declaration for pointX) Thanks for the clarifications. But I am still in the dark. I have literally no clue about *exactly* what your suggestions would entail. What would the effect on the type system of (1) be? Or (2) -- is it just a name-space issue or is it something to do with types. Or (3) -- I have even less clue here. Sorry to be dense Simon

3 3

FunDeps
by John Meacham 14 Feb '06

14 Feb '06

I was curious if making the restriction that fundeps be acyclic would cause them to always be expressible by assosiated types (but obviously not as powerful). my thinking being that every parameter at the origination of a fundep would stay a class parameter and any parameter at the target would become an assosiated type. this rule would be powerful enough to express all of the MTL, and if it is subsumed by assosiated types, it might be an acceptable compromise. however, specifying the ambiguity rules is going to be interesting, but I think we can do so by taking the assosiated types typing rules and intersecting them with the fundeps rules treating fundep targets as assosiated types. hopefully the result will be powerful enough and well specified.. this is just sort of a brainstorming idea and not entirely thought out. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

proposal: standardize interface to Haskell' implementations
by Claus Reinke 14 Feb '06

14 Feb '06

[an innocent question on ghc-users just reminded me of another missed opportunity in previous Haskell definitions: by chosing to ignore the very idea of implementations, they have left tool implementors in a limbo.] these days, there is some momentum for providing Haskell with various tools for refactoring, documentation, profiling, tracing, instance generators, analyzers, pre-processors for extensions, editor modes, interactive interfaces (textual, graphical, visual), .. and even first ides, but all that is hampered by the lack of a standardized interface to functionality that exists in every single Haskell implementation: parsing, type checking, AST, (pretty printing,) semantic information, (evaluation). that functionality is common to most tools, hard (and unneccessary) work to reimplement, and almost impossible to keep up to date, diverting precious man-power from small teams trying to provide much needed tools. all we have at the moment is the haskell-src part of the libraries Language.Haskell.{Parser,Pretty,Syntax), and some Hugs- or GHC-specific APIs (Hugs Server API, package GHC), or other frontends like Programatica, etc.. compare that with Lisp, Smalltalk, SML/NJ and the like, where reflection support means that tool builders get a fantastic head start by being able to reuse available implementation functionality. if you think that isn't the job of a language standard, think again; for instance, there is the ADA Semantic Interface Specification (ASIS) - "an interface between an Ada environment (as defined by ISO/IEC 8652:1995) and any tool or application requiring information from it." http://www.acm.org/sigada/wg/asiswg/ASIS_FAQ.html http://www.acm.org/sigada/wg/asiswg/ I am aware that the precise form of, say, the GHC API is still in flux, but I think Haskell' is a great chance to make a start on standardizing the basics(*), so that those tools will be available for *all* conforming Haskell' implementations, and so that the tool implementers are freed to focus on their core functionality! cheers, claus (*) a standard haskell' api providing the commands of ghci/hugs style interactive systems would be a start, together with an annotated AST, parser/typer/pretty printer. more detailed specifications could be left for future revisions.

7 10

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

Tuple-like constructors
by Pablo Barenbaum 12 Feb '06

12 Feb '06

An awkwardness in Haskell I would like to see solved in Haskell', is the fact that the behavior of tuple-like constructors must be either built-in or "limited". As far as I can see, these are two issues: 1. There is not a way, for the programmer, to define infinite constructors for infinite associated types (such as (,) (,,) (,,,) ... / (a, b) (a, b, c) (a, b, c, d) ...) these must be built-in. 2. There is not a way to define functions operating on all of these types. Instead, different functions (like zip, zip3) must be defined. Something similar happens with liftM, liftM2, ... these are "limited". It seems the language is lacking abstraction, or being misused, when the standard prelude issues this code: zip :: [a] -> [b] -> [(a,b)] zip = zipWith (\a b -> (a,b)) zip3 :: [a] -> [b] -> [c] -> [(a,b,c)] zip3 = zipWith3 (\a b c -> (a,b,c)) Clearly, at least for a human being, it's redundant. I don't know if there already are proposals to solve this. Sorry if I sound aggresive, I'm just trying to help. Excuse my English... Best regards. -- Pablo Barenbaum

10 15

exported pattern matching
by Jim Apple 12 Feb '06

12 Feb '06

Sometimes I'd like to use a smart constructor but have pattern matching as well. There has been talk elsewhere of allowing export of data constructors for /matching/ but not for /construction/: --------module One--------- data Picky a = Nil | One a picky x = if some_complex_thing x then One x else Nil --------module Two--------- f x = g $ picky x g Nil y = y g (One x) y = x h Nil = One True ----------------- I'd like for the function g to be fine and the function h to get a complaint like "error: no constructor 'One'" or, even better, "error: 'One' only works in pattern matching" Jim

7 7

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 11 Feb '06

11 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

RE: First class labels
by Simon Peyton-Jones 10 Feb '06

10 Feb '06

| To make up for this, I've now extended the example code to | include more operations, cryptic infix operators, and more | type class tricks (we have examples of record field selection, | symmetric record concatenation, record field removal, record | field update, record field renaming). Claus I did read your message. I'm afraid I couldn't figure out exactly what you were proposing, so I filed it hoping that the ensuing discussion would clarify. For example, what does it mean to "remove the need to declare labels, make them identifiable as such in use"? I had similar questions about your other two options. Then, the code that you enclosed appeared to show that you could do without any extension at all. Records are a huge swamp with a very large number of possible variants and design choices. Perhaps you might gain more traction if you were ruthlessly specific about what language changes you advocate, and what benefits they would have (versus the existing situation). Simon

2 1