- Haskell-prime - Haskell.org

RE: Strict tuples
by Simon Marlow 21 Mar '06

21 Mar '06

On 21 March 2006 03:10, John Meacham wrote: > On Mon, Mar 20, 2006 at 09:39:41AM -0500, Manuel M T Chakravarty > wrote: >> Apart from the syntactic issues, does anybody else support the idea >> of strict tuples as proposed? I just want to know whether I am >> alone on this before putting it on the wiki. > > I have a few issues though, not entirely easy to articulate. > > I worry about all the (! .. !) types that will appear in interfaces, > making things like (map fst) not work. After some thought, I find myself with a similar view to John. Strict tuples are starting to feel like real language bloat, one tiny addition too much. Remember, every addition we make to the core syntax is multiplied by all the parsers for Haskell and tools that have to grok Haskell, and make the bar ever-so-slightly higher to producing such tools. There's a reason that syntax ends in "tax" :-) By all means have strict tuples in a library somewhere. They don't need to have special syntax. Cheers, Simon

2 1

RE: Re[2]: Strict tuples
by Simon Marlow 20 Mar '06

20 Mar '06

On 20 March 2006 12:26, Bulat Ziganshin wrote: > 2) to allow "changing" of strictness inside existing ADTs, i propose > to "copy" strictness annotations on type arguments to the type > declaration bodies: > > data List a = Nil | Cons (List a) a > type StrictElements a = List !a > > is equal to the: > > data StrictElements a = Nil | Cons (List a) !a So, in fact StrictElements is not compatible with the List type at all (that is, you can't pass a value of type (StrictElements Int) to a function expecting (List Int)). I can envisage that this might be a sound extension, and imlementable, but is it what you mean? I don't think so. I imagine you want a lot of automatic conversion back and forth bewteen strict and lazy types. This is where it gets a *lot* trickier, starting with the type system. > i.e. it's the same list but each element is strict. using strictness > annotation on type constructor itself should mean strictifying of all > other (non-type-variable) fields: > > type StrictList a = !List a > => > data StrictList a = !Nil | !Cons !(List a) a I don't know what !Nil or !Cons mean. > of course, i don't mean introducing new incompatible types - that is a > compiler responsibility (sorry, Simon :) Well, you haven't told me what type system I need to implement, so it's not just an implementation issue. And it seems to me that you *are* introducing incompatible types. Cheers, Simon

1 0

RE: Strict tuples
by Simon Marlow 20 Mar '06

20 Mar '06

On 19 March 2006 14:53, Bulat Ziganshin wrote: > Hello Manuel, > > Sunday, March 19, 2006, 5:35:12 AM, you wrote: > > MMTC> PS: IIRC Clean supports strict tuples. > > i've proposed to allow adding strict mark to any type constructors and > type constructor parameters so that finally we can define any data > structure that can be defined in strict languages. in particular: > > type StrictPair a b = !(,) a b > type StrictElements a b = (,) !a !b > type StrictBoth a b = !(,) !a !b > type StrictFunction a b = !(->) !a !b > > strictMap :: StrictFunction a b -> ![!a] -> ![!b] > > where ![!a] is a strict list with strict elements Bulat, this doesn't constitute a proposal. It leaves too many questions unanswered. If it is supposed to be just syntactic sugar, and I believe that is your intention, then can you show me how the above definitions translate into Haskell 98? I think you'll need to include a lot more detail for this to be a proposal. Cheers, Simon

2 1

Suggestion: refine overlap handling for instance declarations
by Claus Reinke 19 Mar '06

19 Mar '06

overlapping instances with best-fit overlap resolution are useful because they give us an alternative way to write programs that we cannot write directly as long as current Haskell isn't expressive enough: (a) we can't specify that two types in an instance are not equal; but we can use overlap resolution to ensure that equal types are handled by another, more specific instance (b) we can't enable library users to add instances for their types, yet ensure that there will be some instance for every type; but we can use overlap resolution to provide a default instance, to be overridden by more specific instances in library and user code (c) we can't rely on mutual exclusion properties specified in instance contexts to be used to select the appropriate instance because Haskell only looks at instance heads; but we can sometimes wrap our types in extra constructors so that the mutual exclusion is reflected in more and less specific instance heads, with overlap resolution choosing the right one (this is a real pain, brittle against change, and not always possible..) (d) ..this seems to cover most uses discussed so far, but I don't claim this list to be complete. if you know of examples not covered by a-c, please add them by reply! there hasn't been any enthusiasm about changing (c) for Haskell', which isn't to my liking, but nothing I can do much about. I would, however, like to continue arguing in favour of refining overlap handling until we get at least some progress into Haskell' (and addenda). so I propose to add the something like the following to Haskell': ---------- we know how to handle (a) [no overlap needed]: syntax: permit type inequalities as guards in instance declarations: <topdecls> -> .. | 'instance' [<ctxt> '=>'] <head> [ '|' <ineqs> ] [<body>] <ineqs> -> <typevar> '/=' <type> [ ',' <ineqs>] semantics (sketch): - add inequality guards from an instance as guards to the rules for that instance in the CHR - add inequality guards as attributes to the typevars after successful guard evaluation and rule commit remarks: - we only need the extra guard syntax because of (c) above - we restrict inequalities to variables on lhs to simplify semantics - attributed variables are logic programming folklore: variable attributes are simply goals to be reexamined whenever the attributed variable is instantiated; we need them here to ensure that after we have selected a CHR rule based on an inequality, that inequality is not violated by later instantiations -------------------- we can make (b) more explicit: instead of enabling overlapping instances and overlap resolution on a per-module or per-session basis, we can specify which instances we want to use only as defaults: syntax: <topdecls> -> .. | ['default'] 'instance' [<ctxt> '=>'] <head> [ '|' <ineqs> ] [<body>] semantics (sketch): - default instances may be overridden by more specific instances including other default instances, but no such overlap is permitted unless there is a single most specific instance - default instances only apply if there can be no more specific instances; the easiest way to model this is by collecting all instances for the class, select those that are more specific than some default instance, and add type inequality guards that exclude those instantiations from the rule for the default instance - no other instances are affected by overlap resolution remarks: - by declaring all instances as 'default', we could recover the current, indiscriminate overlap handling; but we hardly ever want that, as declaring default instances allows us to be more precise, limiting the impact of overlap handling - once we have type inequality guards in the language, we can be a bit stricter about ruling out overlaps than GHC is at the moment (see Simon's earlier example) - default instances with ground heads (no variables) can be treated like non-default instances (there can't be any more specific instances) - without further analysis, application of default instances has to be delayed until the whole program is visible; that does not prevent separate compilation, it only prevents early application of some instances (those marked as defaults); in other words, separately compiled modules are parameterized by the set of more specific instances for their default instances - we don't want to go through all that trouble for every instance in every class, which is the motivation for being very specific about where we want overlaps to be permitted and resolved cheers, claus

3 3

Keep the present Haskell record system!
by Henrik Nilsson 19 Mar '06

19 Mar '06

Dear all, I'm increasingly convinced that the records should be left alone for Haskell', possibly modulo some minor tweaks to polish the system. While there are a number of reasonable proposals out there for a replacement record system, and while I do agree that a more flexible system would be desirable, there just is no consensus whatsoever as to which one is the way forward. Moreover, my impression is that maintaining backwards compatibility while truly addressing the shortcomings of the present system, almost inevitably would lead to a language with TWO kinds of records. I must say I really don't like that prospect. If the above is true, then that would imply that backwards compatibility would have to be sacrificed in a serious way if we were to move forward with a proposal for a new record system. I don't think there is a case for this in the context of Haskell'. A while ago, I suggested some rules-of-thumb for when serious backwards-compatibility breaking changes might be considered for Haskell'. To recap: If a proposed change breaks backwards compatibility, then it is acceptable only if either 1. very little existing code is likely going to be broken in practice, or 2.1. it is widely agreed that not addressing the issue really would harm the long-term relevance of Haskell', and 2. it is widely agreed that attempting to maintain backwards compatibility would lead to an unwieldy language design, and 3. the proposed design and its implications are well understood, i.e. it has been implemented in at least one system and it has been used extensively, or a strong argument can be made on the grounds of, say, an underlying well-understood theory. From the people who commented on that, there seemed to be some support for this position, and no one, as far as I know, said they thought that the above was too restrictive. My position is that two parallel record systems is so unwieldy so as to not be acceptable. That would imply that fixing the records would break lots of code. That means rule 1 above does not apply. One can probably find some proposals out there that meet criteria 2.3. However, I don't think 2.1 can be argued convincingly. Yes, some people claim that no proper records is the key thing that gets in the way of serious software development in Haskell. I don't believe that as I see lots of serious Haskell software out there that seems to have been developed just fine with the existing records (or not using records at all, or using some kind of "home brewed" records.) (In contrast, it seems to me that lots of serious Haskell software out there do use MPTCs, FDs, and rank-2 or higher types.) Moreover, I think the current record system is being unfairly discredited. Yes, it is certainly not perfect. But by adopting some simple conventions for naming fields to avoid name clashes, it is really not that hard to use them in the way records are used in a language like, say, C. (No, I'm not arguing that C's record system is great, just that that basic kind of records evidentially is enough for supporting some really serious software development efforts.) Moreover, there is scope for improving the present system a little bit without any major changes. Anyway, the present records certainly beats having no records at all hands down, and they are moreover very lightweight and fits very nicely into Haskell. For this, they deserve credit. My proposal is thus that we move forward on records for Haskell' by deciding to essentially keep the current record system. All the best, /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.

11 22

Re[2]: [Haskell-cafe] STUArray
by Bulat Ziganshin 18 Mar '06

18 Mar '06

Hello Chris, Sunday, March 12, 2006, 2:05:09 PM, you wrote: CK> Is GHC.PArr documented? it's perfectly documented in module sources itself :) you can also look at the ndpFlatten directory in ghc compiler's sources. i've successfully used them in my program, of course this makes program faster but only-GHC compatible. so i plan to document it on http://haskell.org/haskellwiki/Arrays and incorporate it in Data.Array.* infrastructure so that strict arrays will be emulated under Hugs. CK> The -fparr option is not in the 6.4.1 User's Guide. they just forgot to do this :) btw, strict arrays will be a good candidate for Haskell-prime library standard -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

RE: Infix expressions
by Simon Peyton-Jones 17 Mar '06

17 Mar '06

| The second header line shows categories, whereas the links in the grey | boxes are to articles. The "idioms" category collects together articles | that are about idioms. | | We could have an "idioms" or "programming techniques" article as well, | of course. It only needs to be written. Interesting. I thought there would be a rationale! But my point is this: I didn't even know that there is a concept of a "category" on the Haskell web site. And I visit it regularly. An innocent visitor certainly won't. Now I know that there is such a concept, but I have no idea what it might mean, or how I might use it. My suggestion: by all means have categories, whatever they are. But can we arrange the home page of Haskell.org so that a new and ignorant visitor can simply look on the visible page (without prior knowledge) and know where to go? And can there be some information readily accessible that explains what categories are, and how to use them and add to them? Sorry to be stupid about this. Simon

2 1

RE: Infix expressions
by Simon Peyton-Jones 16 Mar '06

16 Mar '06

| > Incidentally, I looked on the Haskell home page for links to programming | > idioms and advice, but came up empty. The obvious place to look was | > under "Using Haskell", but I didn't find anything. Was I being stupid? | > Haskell.org is the obvious place to look for advice about programming in | > Haskell. | | There should be a link to "Idioms" above the grey boxes? Oh yes so there is! But what is the rationale for what goes in those two header lines, and what goes in the grey box lists? Why would "idioms" be in the first place but not the second, and FAQ in the second but not the first? Perhaps we could have just the grey boxes? (Incidentally "idioms" is too short to tell me "follow me". Something like "Programming techniques" would be more suggestive.) Simon

2 1

RE: relaxed instance rules spec (was: the MPTC Dilemma (please solve))
by Simon Peyton-Jones 16 Mar '06

16 Mar '06

Claus, I urge you to read our paper "Understanding functional dependencies via Constraint Handling Rules", which you can find here http://research.microsoft.com/%7Esimonpj/papers/fd%2Dchr/. It will tell you more than you want to know about why relaxing apparently-conservative rules is entirely non-trivial. It's one of those areas in which it is easy to suggest a plausible-sounding alternative, but much harder to either prove or disprove whether the alternative a sound one. The paper describes rules we are reasonably sure of. It would be great to relax those rules. But you do need to have a proof that the relaxation preserves the properties we want. Go right ahead! The paper provides a good framework for such work, I think. Simon | -----Original Message----- | From: Claus Reinke [mailto:claus.reinke@talk21.com] | Sent: 28 February 2006 19:54 | To: Simon Peyton-Jones; haskell-prime(a)haskell.org | Subject: relaxed instance rules spec (was: the MPTC Dilemma (please solve)) | | >The specification is here: | >http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extension s.html#instance-decls | | two questions/suggestions about this: | | 1. there are other termination criteria one migh think of, though | many will be out because they are not easy to specify. but here | is an annoyingly simple example that doesn't fit the current rules | even though it is clearly terminating (it's not even recursive): | | class Fail all -- no instances! | | class TypeNotEq a b | instance Fail a => TypeNotEq a a | instance TypeNotEq a b | | class Test a b where test :: a -> b -> Bool | instance TypeNotEq a b => Test a b where test _ _ = False | instance Test a a where test _ _ = True | | main = print $ (test True 'c', test True False) | | never mind the overlap, the point here is that we redirect from | Test a b to TypeNotEq a b, and ghc informs us that the | "Constraint is no smaller than the instance head". | | it is true that the parameters don't get smaller (same number, | same number of constructors, etc.), but they are passed to a | "smaller" predicate (in terms of call-graph reachability: there | are fewer predicates reachable from TypeNotEq than from | Test - in particular, Test is not reachable from TypeNotEq). | | this is a non-local criterion, but a fairly simple one. and it seems | very strange to invoke "undecidable instances" for this example | (or is there anything undecidable about it?). | | 2. the coverage condition only refers to the instance head. this | excludes programs such as good old record selection (which | should terminate because it recurses over finite types, and is | confluent -in fact deterministic- because of best-fit overlap | resolution): | | -- | field selection | infixl #? | | class Select label val rec | label rec -> val where | (#?) :: rec -> label -> val | | instance Select label val ((label,val),r) where | ((_,val),_) #? label = val | | instance Select label val r => Select label val (l,r) where | (_,r) #? label = r #? label | | now, it is true that in the second instance declaration, "val" is | not covered in {label,(l,r)}. however, it is covered in the recursive | call, subject to the very same FD, if that recursive call complies | with the (recursive) coverage criterion. in fact, for this particular | task, that is the only place where it could be covered. | | would it be terribly difficult to take such indirect coverage (via | the instance constraints) into account? there'd be no search | involved (the usual argument against looking at the constraints), | and it seems strange to exclude such straightforward "consume | a type" recursions, doesn't it? | | cheers, | claus

8 20

RE: Infix expressions
by Simon Peyton-Jones 16 Mar '06

16 Mar '06

I often wish that cool tricks like this could be collected on the Haskell web site. Now that it's a wiki, anyone could do that. Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | oleg(a)pobox.com | Sent: 15 March 2006 04:34 | To: doaitse(a)cs.uu.nl; haskell-prime(a)haskell.org | Subject: Infix expressions | | | Doaitse Swierstra wrote: | > In Haskell we write `f` in order to infixify the identifier f. In ABC | > the stuff between backquotes is not limited to an identifier, but any | > expression may occur there. This would allow one to write e.g. | > | > xs `zipWith (+)` ys | | Chung-chieh Shan and Dylan Thurston showed the Haskell98 solution for | exactly the same example, in their article `Infix expressions', | back in 2002: | http://www.haskell.org/pipermail/haskell-cafe/2002-July/003215.html | | For ease of reference, here's their elegant solution: | | > infixr 0 -:, :- | > data Infix f y = f :- y | > x -:f:- y = x `f` y | > | > main = print $ [1,2,3] -: zipWith (+) :- [4,5,6] | | | For completeness, here's the `dual': | | > infixr 5 -! | > (-!) = flip ($) | > infixr 5 !- | > (!-) = ($) | > | > add2 x y = x + y | > add3 x y z = x + y + z | > add4 x y z u = x + y + z + u | > | > testa1 = 1 -! add2 !- 3 + 4 | > testa2 = 1 -! add3 1 !- 3 + 4 | > testa3 = 1 - 2 -! add4 1 5 !- 3 * 4 | | All code is Haskell98. | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

5 5