March 2006 - Haskell-prime

Restricted Data Types Now
by oleg＠pobox.com 22 Mar '06

22 Mar '06

It seems we can emulate the restricted data types in existing Haskell. The emulation is good enough to run the examples recently suggested on this list. So, we can start gaining experience with the feature. The emulation involves a slight generalization of the Monad class -- something that also addresses concerns by Amr Sabry http://www.haskell.org/pipermail/haskell/2005-January/015113.html that is, defining monad-like things with additional value constraints. The generalization of the Monad class seems to be backward compatible: > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} > > module RestrictedMonad where > > import List > > class MN2 m a where > ret2 :: a -> m a > fail2 :: String -> m a > > class (MN2 m a, MN2 m b) => MN3 m a b where > bind2 :: m a -> (a -> m b) -> m b That is, we introduce two classes, and we spell out the types of values produced by monadic computations. The standard monad stuff seems to work, at least in the tried cases. For example, we can define Maybe monad in the traditional way > instance MN2 Maybe a where > ret2 = Just > fail2 _ = Nothing > > instance MN3 Maybe a b where > bind2 (Just x) f = f x > bind2 Nothing _ = Nothing and can write the regular code > test3f () = bind2 (ret2 "a") (\x -> ret2 $ "b" ++ x) > test3f' () = bind2 (fail2 "") (\x -> ret2 $ "b" ++ x) whose inferred type is *RestrictedMonad> :t test3f test3f :: (MN3 m [Char] [Char]) => () -> m [Char] which is quite reasonable. We can instantiate that to the Maybe monad: > test3:: Maybe String = test3f () *RestrictedMonad> test3 Just "ba" Let us now run the example suggested by John Meacham > data Eq a => Set a = Set [a] deriving Show > unSet (Set x) = x > > singleton :: Eq a => a -> Set a > singleton x = Set [x] BTW, the Eq constraint in singleton's signature is forced upon us. If we give the signature, we must mention the constraint. OTH, we can omit the signature and it will be inferred. > instance Eq a => MN2 Set a where > ret2 = singleton > > instance (Eq a,Eq b) => MN3 Set a b where > bind2 (Set x) f = Set (nub . concatMap (unSet . f) $ x) Again, we cannot forget the Eq constraints, because the typechecker will complain (and tell us exactly what we have forgotten). Now we can instantiate the previously written test3f function for this Set monad: > test4 :: Set String = test3f () *RestrictedMonad> test4 Set ["ba"] The latter code shows that the Eq constraint (required by nub) is indeed being provided by the `monad', although the test3f function had _no_ Eq constraints. > test5 = case test3f () of Set x -> nub x Here's another similar example. Again, test6 per se has no Eq constraints (and it is polymorphic over the value a) > test6 x = bind2 (ret2 x) (\x -> ret2 x) > test7 = case test6 True of Set x -> nub x > test7' = case test6 True of Just x -> x *RestrictedMonad> :t test6 test6 :: (MN3 m a a) => a -> m a Here's Ashley Yakeley's recent example: > class HasInt a where > getInt :: a -> Int > instance HasInt Int where > getInt = id > instance HasInt Bool where > getInt = const 1 > > data HasInt a => T a = T Int a deriving Show > > -- forced constraint > instance HasInt a => MN2 T a where > ret2 a = T (getInt a) a > > instance (HasInt a, HasInt b) => MN3 T a b where -- forced constraints > bind2 (T i1 i2) f = let (T _ b) = f i2 in T i1 b > > foo () = bind2 (ret2 True) (const (ret2 3)) > > fooT :: T Int > fooT = foo ()

2 2

Collections interface
by Jim Apple 22 Mar '06

22 Mar '06

I have created a ticket to make a standard collection interface. It is here: http://hackage.haskell.org/trac/haskell-prime/ticket/97 Obviously, it will be tough to figure out what the library can look like without knowing what MPTC's will look like. Jim

1 0

important news: refocusing discussion
by isaac jones 21 Mar '06

21 Mar '06

Greetings, While discussion on this mailing list has been coming fast & furious, actual tangible progress, even as measured on the wiki, has not been as fast. To remedy this, we propose to focus immediately and intently on a few of the most critical topics, and to focus all of our energies on them until they are done. We'd like to go so far as to ask folks to drop discussion on other items until these are solved. The goal of this approach is that we will spend the most time on the critical (and hard) stuff, instead of leaving it for last. We know that we can spend a _lot_ of time and energy discussing relatively small things, and so we want to make sure that these relatively small things don't take up all of our time. We will tackle them later. The topics that John and I feel are critical, and rather unsolved, are: * The class system (MPTC Dilemma, etc) * Concurrency * (One more, perhaps standard libraries) The logic here is that Haskell' will be accepted by the community if we solved these problems, and if we go with some of the most robust and uncontroversial extensions already out there. We will probably partition the committee into subcommittees to focus on each topic. Our goal will be to bring these topics to "beta" quality by mid April. That is, something that we could be happy with, but that perhaps needs some polishing. After that, we may try to pick the next most critical topics with the goal of having everything at "beta" quality by the face-to-face we're hoping to have at PLDI in June. With an eye toward considering related proposals together, we've added a "topic" field to the wiki, and a new query to the front page which groups the proposals by topic: http://hackage.haskell.org/trac/haskell-prime/query?status=new&status=assig… I'd like to ask folks to please bring currently open threads to a close and to document the consensus in tickets. Anyone can edit tickets, so please don't be shy. your chairs, Isaac Jones John Launchbury -- isaac jones <ijones(a)galois.com>

3 3

Ranges and the Enum class
by Aaron Denney 21 Mar '06

21 Mar '06

Sometime back on one of the other Haskell lists, there was a proposal to not have the floating types instances of Enum and instead have some other class to which [a, b..c] desugars. That is, rename enumFromThen and friends and put them in another class. Put simply, Float and Double should not support succ and pred (unless, perhaps, they map to the next greater/lesser representable number, which would also be confusing). I can even see an argument for not allowing Float or Double to be used for ranges either, as the steps may not be exact, which in practice turns out to be very confusing. This is a wart I would really like to see get fixed. -- Aaron Denney -><-

5 10

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