January 2006 - Haskell-prime

an example of why users should be able to edit tickets
by Isaac Jones 25 Jan '06

25 Jan '06

Not to beat a horse... Here's an example of why users should be able to edit tickets. If Duncan could do anything with the wiki, I could ask him to bring together the various semi-formal proposals into a ticket or three tickets. Then we can reasonably weigh it in with the other proposals later on, and perhaps move it to the wiki if we're strongly considering it. No one has replied to Duncan in 2 days, but is it actually the case that no one believes these ideas should be considered further? Since I am committed to taking input from the community, I want to be able to watch whether or not these threads get to a conclusion. I don't want to use my email reader for this; they're open loops that I want to track in a ticket system. peace, isaac

1 0

more flexible partial application
by Sebastian Sylvan 25 Jan '06

25 Jan '06

Are there any subtle reasons for why something like the following couldn't be allowed? > foo x y z w = ... > bar x w = foo x _ _ w I.e. a more flexible version of partial application. This would be translated too > bar x w = \y z -> foo x y z w I.e a function which takes the "_" parameters in the same order they were encountered in the function application. Some other languages allow this, such as Nemerle. Quite handy. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

7 9

forwarded message on the importance of libraries
by Isaac Jones 24 Jan '06

24 Jan '06

Garry Hodgson writes: "Isaac Jones" <isaac.jones(a)gmail.com> wrote: > Haskell' will be a conservative refinement of Haskell 98. It will > be the work of this committee to adopt a set of language > extensions and modifications and to standardize *a new set of > libraries.* [emphasis mine] excellent. just please please please don't give short shrift to the libraries, as this is what will make or break any effort to make haskell more useful to the development community at large. have a look at the set of libraries that come with python to get an idea of a useful starting point. i recognize that libs are not academically sexy, and that this would require a great amount of resources. but starting with the notion that haskell should have an equivalent set, and then giving ground where necessary, would be far better than assuming a minimal set that users will augment. because they won't. they'll just use python. > This standard will reflect the realities of developing > practical applications in the Haskell language. excellent. play close attention to the "out of the box" experience. if i can install it, run the examples, maybe have some useful command among them, i'm far more likely to invest the effort to go further. make sure it plays well with others. if i can write code that i can use alongside my other code in other languages, integrate into my build system, and distribute in running form without requiring handstands from my users, i'm far more likely to use it for actual work. there's a threshold of effort required to adopt any new language. the lower you can make that threshold, the more people will take that first step. note: please don't anyone take this as a python flame, or an invitation to start one. i love python. i love haskell. i use python on a daily basis because i can get stuff done with it. ---- Garry Hodgson, Technical Consultant, AT&T Labs

3 2

Wildcard type annotations
by Philippa Cowderoy 23 Jan '06

23 Jan '06

Would it be possibly to support a 'wildcard' type (probably written "_" to match the pattern-matching syntax) that matched any inferred type without requiring any actual degree of polymorphism the way a type variable would? This would allow 'partial' annotations, making it easier to provide the type system with extra information without having to supply potentially complicated parameters that it can infer itself. Possibly the same thing could also be used in a type's constraint to indicate zero or more predicates other than those specified. -- flippa(a)flippac.org Society does not owe people jobs. Society owes it to itself to find people jobs.

5 9

Hierarchical module namespace extension not sufficiently flexible
by Duncan Coutts 23 Jan '06

23 Jan '06

To the Haskell' committee, I think the hierarchical module namespace extension has been generally successful. One of the aims was to enable people to use names like Set.union rather than everyone having to prefix the module name onto the function name like setUnion. The one area where this doesn't quite work is in large packages that consist of many many modules. Examples include Gtk2Hs and HOpenGL. The problem with these packages is that they do use modules; they do not consist of a flat name space. They use the same names in different modules. This wouldn't be too much a problem except that these large packages consist of many modules. In the case of Gtk2Hs it has more that 100 modules. So it is impractical to import each module separately. Basically what I want is an extension which allows me to write: > import Graphics.UI.Gtk and then use > ... Button.label ... At the moment this is not possible and we have to export buttonLabel from Graphics.UI.Gtk. This is exactly what we wanted to avoid by using hierarchical module names. So I'm not suggesting any particular concrete extension (though people have suggested various things, see below). I'd be happy with anything that would allow me to write the above code. So that's it. That's what we want to do for large practical libs. It seems reasonable. Every other modern language can do it (see eg the Gtk+ bindings for C++,Java,Python,Ruby,Ocaml,etc). This issue has been discussed before and people have made various suggestions: I originally brought it up: http://www.haskell.org/pipermail/haskell/2004-December/015085.html It was discussed more a few months later: http://www.haskell.org/pipermail/haskell/2005-March/015462.html and the discussion moved to the libraries list: http://www.haskell.org/pipermail/libraries/2005-March/thread.html Duncan

2 2

Numeric class lattice reworking?
by Aaron Denney 23 Jan '06

23 Jan '06

One of the complaints I've seen with people trying to do various mathematical tasks in haskell is the inflexibility of the numeric prelude. The biggest issue is having (*) and (+) in the same typeclass, but other generalizations are certainly possible. MPTC would allow such things as modules with (*) having type a -> b -> b which covers everything from group actions to scalar multiplication of vectors. Actually, a -> b -> c would be nice. See http://haskell.org/hawiki/DimensionalizedNumbers this would let me have multiplication of numbers with units, enforced at the type level, while keeping the safety of (+) :: a -> a -> a. Is there any chance of this sort of breakup happening? -- Aaron Denney -><-

2 1

[Haskell'] Haskell': Kicking off the process of defining the next Haskell standard.
by Isaac Jones 21 Jan '06

21 Jan '06

let haskell' = succ haskell98 in Announcing the Haskell' ("Haskell-Prime") process. A short time ago, I asked for volunteers to help with the next Haskell standard. A brave group has spoken up, and we've organized ourselves into a committee in order to coordinate the community's work. It will be the committee's task to bring together the very best ideas and work of the broader community in an "open-source" way, and to fill in any gaps in order to make Haskell' as coherent and elegant as Haskell 98. Our task is broadly defined by our mission statement: The Haskell programming language is more-or-less divided into two "branches". The Haskell 98 standard is the "stable" branch of the language, and that has been a big success. A lot of progress has been made over the last few years in the "research" branch of the Haskell language. It is constantly advancing, and we feel that it is time for a new standard which reflects those advancements. Haskell' will be a conservative refinement of Haskell 98. It will be the work of this committee to adopt a set of language extensions and modifications and to standardize a new set of libraries. We will strive to only include tried-and-true language features, and to define them at least as rigorously as Haskell 98 was defined. This standard will reflect the realities of developing practical applications in the Haskell language. We will work closely with the rest of the Haskell community to create this standard. Your Haskell' Committee is as follows (slightly munged email addresses follow): * Manuel M T Chakravarty <chak at cse.unsw.edu.au> * John Goerzen <jgoerzen at complete.org> * Bastiaan Heeren <bastiaan at cs.uu.nl> * Isaac Jones <ijones at galois.com> * John Launchbury <john at galois.com> * Andres Loeh <loeh at iai.uni-bonn.de> * Simon Marlow <simonmar at microsoft.com> * John Meacham <john at repetae.net> * Ravi Nanavati <ravi at bluespec.com> * Henrik Nilsson <nhn at cs.nott.ac.uk> * Ross Paterson <ross at soi.city.ac.uk> * Simon Peyton-Jones <simonpj at microsoft.com> * Don Stewart <dons at cse.unsw.edu.au> * Audrey Tang <autrijus at gmail.com> * Simon J. Thompson <S.J.Thompson at kent.ac.uk> * Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> * Stephanie Weirich <sweirich at cis.upenn.edu> The editors are Isaac Jones and John Launchbury. Feel free to contact any of us with any concerns or questions. If you don't know who to direct your questions to, email Isaac Jones ijones(a)syntaxpolice.org. Community involvement is vital to our task, and there will be a way for members of the community to make formal proposals. In the opening phases, please use these more informal resources to help us coordinate Haskell': * The haskell-prime mailing list. All technical discussion will take place here, or (if other meetings take place) be reported here. Anyone can subscribe, and any subscriber can post questions and comments, and participate in discussions. Anyone can read the list archives. http://haskell.org/mailman/listinfo/haskell-prime * A wiki / issue tracking system to document consensus and to track ongoing tasks. This system is publicly readable, but only committee writable so that we may present it as the "official" output of the committee. If you ever feel that the wiki is not accurate as to the consensus, please alert the committee! http://hackage.haskell.org/trac/haskell-prime * A darcs code repository for experiments, proposed libraries,and complex examples. darcs is a decentralized system, so anyone can use it, but patches should be sent to Isaac Jones: http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode Please join us in making Haskell' a success. your, Haskell' Committee p.s. Please feel free to forward this announcement to appropriate forums.

1 0