February 2006 - Haskell-prime

RE: proposal: standardize interface to Haskell' implementations
by Simon Peyton-Jones 21 Feb '06

21 Feb '06

| (*) 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. Claus, A reasonable suggestion, but I'm unsure what you actually have in mind. I think that perhaps you mean that Haskell' should specify a (Haskell) library through which one can compile, load, and execute Haskell programs? Is that right? That is, you have in mind precisely the sort of thing that GHC-as-a-library tries to offer? I ask because that isn't exactly what Java reflection, for example, offers. If that is what you have in mind, then yes indeed, it would be great to have such an interface specified. But it's a big task. The data types involved are large, and there are lots of design choices. We've simplified the problem in GHC by exposing some of GHC's internal types (e.g. Type, Class, TyCon, Id etc) which have themselves evolved over time. And that's before you start asking about what interfaces are suitable for loading, renaming, typechecking, optimising etc. I, for one, would love it if you and others felt able to contribute to the Haskell-as-a-library interface (i.e. what it should look like to the client). Whether we'd be anywhere near done for Haskell' I'm less certain. There's a (GHC-specific) Wiki page for suggestions about GHC as a library, which might be good place to start. http://haskell.org/haskellwiki/GHC/As_a_library Simon

4 3

Strict Haskell debate
by Andy Gill 17 Feb '06

17 Feb '06

I'd like to see a way of enforcing return strictness, that is where you have confidence that what a function is returning is fully evaluated. Imagine a function hstrict; hstrict :: a -> a you can define hseq with this. hseq :: a -> b -> b hseq a b = hstrict a `seq` b and $!!. ($!!) :: (a -> b) -> a -> b a $!! b = a $! (hstrict b) With hstrict you can write functions in the style. fun f a b c = hstrict $ .... where ... ... and also fun f a b c = hstruct $ bla { abc = def , cfg = tts , ... } We know that strictness plays no part in the returned value after the function is finished evaluating, which is a Useful Property. What I'd like is a efficient hstrict, that does not re-evaluate anything that has already been hstrict-ified. In the same way as we evaluate an object, we could strictify an object using a similar (low-level) mechanism. So the cost of calling hstrict would be amortized away to almost nothing. How much work would this be to add hstrict GHC? A extra bit in the runtime representation? Could we use the speculation mechanism to do it? Andy Gill

2 2

Proposal: pattern synonyms
by Conor McBride 17 Feb '06

17 Feb '06

Hi folks Having spent the last week hacking, I've found a common irritation, so I have a proposal to mitigate it. Of course, this issue may not bug anyone else, so I'm a little hesitant. In pessimal pedagogical order, the proposal: pattern synonyms. I want to be allowed to write stuff like P x y z = C x (y, [z]) defining a capitalised symbol with parameters used linearly in a pattern on the right-hand side. Pattern synonyms should be fully applied and expand macro-style wherever patterns or terms appear, hence should not give rise to cycles, just like type synonyms. It seems (and is) trivial. Why would it help? Well, it would help me, because I often write more complex types than strictly necessary to represent data in order to expose its structure and thus gain free equipment. For example, taking newtype Comp f g x = Comp (f (g x)) -- applicative if f and g are newtype Prod f g x = Prod (f x, g x) -- applicative if f and g are newtype Const x y = Const y -- applicative if x is a monoid newtype Id x = Id x -- trivially applicative newtype Any = Any Bool -- equipped with the disjunctive monoid structure all of which I keep lying around anyway, I might well write type MyEffect = Comp Maybe (Prod (Const Any) Id) which is the same as type MyEffect' x = Maybe (Bool, x) except that (1) MyEffect :: * -> * is an applicative functor without further ado (because it is composed from suitable components), hence I get lots of free kit for traversing data with it. (If you're interested, we use this to update terms where some variables have been changed and others have been deleted entirely: we want to know the new term if it exists, and whether it differs from the old one.) MyEffect' is meaningless. (2) Pattern matching on MyEffect x is much more annoying than on MyEffect' x. I want to write Bang :: MyEffect x Bang = Comp Nothing Bing :: x -> MyEffect x Bing x = Comp (Just (Prod (Any True), Id x)) Dull :: x -> MyEffect x Dull x = Comp (Just (Prod (Any False), Id x)) and have done with it. Does this happen to anyone else? Would pattern synonyms help? Thought I'd ask, anyway. All the best Conor

7 7

proposal for moving forward
by Isaac Jones 16 Feb '06

16 Feb '06

We have a fairly large list of proposals on the wiki, but in my opinion, we need to start to discuss how they interact with each-other, and what the "big ideas" of this standard are. I've identified two sets of proposals that need clarification or fixing. These are a sort of "meta proposal" that reference a handful of other proposals. solve the MultiParamTypeClassDilemma: http://hackage.haskell.org/trac/haskell-prime/ticket/90 bring together various class-related tickets into something coherent: http://hackage.haskell.org/trac/haskell-prime/ticket/93 Can we identify more? Here are all of the proposals: http://hackage.haskell.org/trac/haskell-prime/report/9 The categorization of proposals at that link is a first-pass at what might be in or out, and is just for discussion. My intuition (and a proposal) is that our job will be to: 1. conservatively standardize some of the most robust extensions, 2. clean up the class hierarchies and some libraries, 3. solve the MPTC dilemma (see above), and 4. pick one other "big idea" such as records or bang patterns. Thoughts? peace, isaac

2 2

Parallel list comprehensions
by John Hughes 16 Feb '06

16 Feb '06

I noticed ticket #55--add parallel list comprehensions--which according to the ticket, will probably be adopted. I would argue against. Firstly: because in its more general forms the notation is confusing. Try this example: [(i,j,k) | i<-[1..3], j<-[1..3] | k <- [1..9]] In general it's hard to predict how the elements from each set of generators and filters will match up. Secondly: because the notation lacks expressive power. When I use zip in a comprehension, it's often in a definition like this one: positions x xs = [i | (i,x') <- zip [0..] xs, x==x'] I'm zipping the two lists together *so that I can relate the two* in a subsequent filter. The parallel comprehension notation cannot express this. (You can certainly write wrong_positions x xs = [i | i <- [0..] | x' <- xs, x==x'] but it does the wrong thing). Thirdly: because even in situations where it can be applied, the gain is small. Using zip explicitly is almost equally concise, and (thanks to being explicit) more readable and understandable. My opinion may be coloured by the fact that I never use the things. However, I think it's a mistake to add rarely used features with a small payoff to the language. It just makes the language larger, harder to learn, and harder to read for all but the expert, without much corresponding benefit. John

16 23

ExistentialQuantifier
by Ross Paterson 16 Feb '06

16 Feb '06

Is this the same as ExistentialQuantification? (And what would an existential in a covariant position look like?)

4 7

Labels and the tentative solution to the MPTC Dilemma
by oleg＠pobox.com 16 Feb '06

16 Feb '06

This message shows the (extensible polymorphic) record selection code that requires neither overlapping instances and not even undecidable instances. Therefore, it works both in GHC and Hugs. This constructively shows that it is possible to write less-trivial code using functional dependencies and multi-parameter type classes as had been specified by Mark P. Jones -- that is, abiding by his syntactic decidability constraints. Therefore, if Haskell' standardized the current practice -- which is implemented _both_ by GHC and Hugs (with no overlapping instances, no undecidable instances), the result can still be useful. I do admit that writing the code below required jumping through more hoops than I would like, but I was prepared to suffer for the principle. The code highlights the benefits of the type equality predicate. With the type equality predicate, many common (albeit not all) uses of overlapping instances can be eliminated. It seems that overlapping instances is one of the more objectionable extensions, and not likely to be adopted in Haskell''. I have the feeling the remaining uses of overlapping instances can be eliminated likewise. That has the implication for the label proposal: it seems that introducing labels _without_ the total label equality predicate is not useful, as any serious use of labels in type-class programming would require overlapping instances (which are unlikely to be standardized). I personally find introducing labels via 'data' declaration isn't that big of an inconvenience, and I found the fact that these 'labels' behave exactly like nullary data/type constructors beneficial and elegant. {-# OPTIONS -fglasgow-exts #-} -- Records with very few extensions (no overelapping instances! -- and even no undecidable instances!) -- See the HList paper for additional explanations and details module SRec where -- Labels data L1 = L1 data L2 = L2 -- Equality predicate on labels data HTrue ; data HFalse class TypeEq a b c | a b -> c class EqL1 a c | a -> c instance EqL1 L1 HTrue instance EqL1 L2 HFalse class EqL2 a c | a -> c instance EqL2 L1 HFalse instance EqL2 L2 HTrue instance EqL1 b c => TypeEq L1 b c instance EqL2 b c => TypeEq L2 b c typeEq :: TypeEq a b c => a -> b -> c typeEq = typeEq -- Records are type-level associative lists -- Following Claus Reinke's notation infixl #? (#?) :: Select () label val rec => rec -> label -> val (#?) = lookp () class Select dummy label val rec | label rec -> val where lookp :: dummy -> rec -> label -> val instance (TypeEq label l tr, ProjLabel r l, Select' tr label val r) => Select () label val r where lookp () r label = lookup' (typeEq label (proj'label r)) r label class Select' tr label val rec | tr label rec -> val where lookup' :: tr -> rec -> label -> val instance Select' HTrue label val ((label,val),rest) where lookup' _ ((_,v),_) _ = v instance (TypeEq label l tr, ProjLabel rest l, Select' tr label val rest) => Select' HFalse label val (a,rest) where lookup' _ (_,r) label = lookup' (typeEq label (proj'label r)) r label class ProjLabel r l | r -> l where proj'label :: r -> l instance ProjLabel ((l,v),r) l where proj'label ((l,v),r) = l r1 = ((L1,True),((L2,'a'),((L1,["who's calling"]),()))) test1 = r1 #? L1 test2 = r1 #? L2

3 2

Haskell' Status
by Isaac Jones 16 Feb '06

16 Feb '06

I'll try to occasionally post an announcement of the the status of Haskell'[1], the next Haskell standard, so that you can all be aware of my thinking, and our current place in the timeline. There is a list of proposals and a "strawman" categorization of them on the wiki[2]. The categorization reflects someone's current thinking about what's in and out, but it's really just for discussion at this phase. The timeline for this effort is also on the wiki[4]. You'll notice that it's very aggressive; we plan to announce something at the next Haskell Workshop in September. Our current spot in the timeline is that we're meant to be brainstorming, discussing, and refining proposals. I've just posted some leading questions [3] in order to focus the discussion a bit. I can't help but notice that there is a lot of excitement (and support?) for a larger standard; one that would have a bigger impact. I think that part of the Haskell' effort should be to make a plan for moving forward. At the very least we should have a set of recommendations for what the community needs to work on between this and the next standard; what are the most promising proposals and what needs to happen to make them a reality. I think that the wiki will be a great resource for any future standard, and we should work to make it as nice as possible. Please reply to the Haskell' mailing list, and email me if you have any questions. peace, isaac [1] Haskell' Wiki: http://hackage.haskell.org/trac/haskell-prime [2] list of proposals and strawman categorization: http://hackage.haskell.org/trac/haskell-prime/report/9 [3] plan for moving discussion forward http://www.haskell.org//pipermail/haskell-prime/2006-February/000582.html [4] The TimeLine is here. Ascii text of the timeline follows (might not make sense unless you use a proportional font: http://hackage.haskell.org/trac/haskell-prime/wiki/TimeLine Write Report----Review---- | | Edit | Discuss / Refine--|---------- | | | | | | | brainstorm----------- | | | | | | | | | | | setup | | | | | | | | | | | | | ------------------------------------------------------------------- 10 | 11 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 2005 2006 ------------------------------------------------------------------- | | | | | | Face-To-Face? | Strawman Trial Decision Announce @HW

1 0

Export lists in modules
by Christopher Brown 15 Feb '06

15 Feb '06

Hi, I am not sure if this has been mentioned before, but something I would really find useful is the ability to tell Haskell to export everything in a function except for some named functions. The problem at the moment is that if you have a large file with lots of functions and you want to export everything in that file apart from one function, then you have to either: export explicitly every function apart from the function you want; import the module hiding the function The first is time consuming and prone to errors and the second raises issues about making libraries portable. I may want to produce an API for example and not export a particular function for a particular reason - I don't want people who use my API to have to use import hiding every time they use it. What does anybody think? Chris. Christopher Brown Ph.D. Student University of Kent. UK. http://www.cs.kent.ac.uk/people/rpg/cmb21/index.html

1 0

Re: First class labels
by Claus Reinke 15 Feb '06

15 Feb '06

Hi Andrew, > Claus, I don't get part of the motivation this proposal, but it might be > because I don't use records. that would be an obstacle, as the major other application would probably be type-class-level programming;-) >What is the need for labels that are global between modules? that's actually a more general problem with Haskell development, whenever you're trying to combine two independently developed sub-projects that define their own auxiliary classes/instances/data for the same purpose (e.g., I've run into wanting to combine two libraries each of which had rolled their own variation of monad transformers, before those arrived in the standard libraries). usually, you'd be trying to keep the subprojects separate from each other, and with the notable exception of instances, Haskell's module system allows you to do that. however, there are cases where the subprojects are just doing the same thing twice (and where lots of explicit conversions are more confusing than useful). you can still define your own local data types and get module separation, and you *do* want the subprojects to talk about *different* Either types, if they are using those to instantiate Error Monads in different ways. but you wouldn't want each of your packages to talk about a different type of integers, nor would you want to write conversion routines between A.String and B.String, or before using C.Bool in conditionals. in my experience, labels, once separated from records, fall into the same category, so there should be a common root for their declarations, just as there is a common root for Char, or Bool. > Ie, if OpenGL and GUI each have their own > pointX label, do you really want to identify them? That seems a bit > hazardous, so I would think the payoff needs to be big. Can you give an > argument for why labels should be global? Is what TREX does already? note that this need not compromise type-safety in any way. you could still declare your types, including labels, locally, and if you are willing to change the sources of say, OpenGL and wxWidgets, you could achieve the sharing effect by factoring out their common label definitions. the only problem is that it isn't practical to rewrite packages for composition, and that Haskell's module system does not provide well for open components. the only thing that would change is that developers would get a chance to decide whether or not they want to share their label constants with other packages they might know nothing about. if they are defining a 2d cartesian coordinate system, they probably want to share even the records (not to mention any auxiliary functions..). note also, that only the labels and their types would be shared, not the field types those labels are associated with, if those labels are use to implement some variant of records. if, as happens to be the case, OpenGL uses Double coordinates, while wxWidgets uses Ints, the type system would still prevent us from mixing those: the values paired with the labels would differ in their types! and yes, TREX labels, while not first-class, are implicitly declared. so there are no record type declarations, either, but you can still wrap your records into data constructors of different types if you watn/need to distinguish between otherwise type-compatible records. > Also, it seems to me that your proposal has two goals that could be > separated, 1. implicit declaration of labels, and 2. identification of > same-named labels across modules. Does it make sense to consider each > independently? yes, that's true in a sense, and I tried to outline different options, but 1/2 are really just different means that need to be combined to achieve the purpose (implicit declarations without sharing, ie. implicitly-declared, module-specific labels, would be a mere convenience, but wouldn't solve the problem; sharing constraints as a separate concept would be interesting, and I mention that when outlining option 2, but they are much too complicated for this simple purpose; and common imports would be useless if you'd had to go in there and add new explicit label declarations every time you wanted to use another package's labels). >You can reply to the list if you'd like. thanks, then I'll do so. if only to mention that I'm getting more off-list responses and queries. that is very encouraging, but since I don't have write access to the wiki, it is probably best to keep the discussion on the list, unless it is something of no general interest. cheers, claus

1 0