- Haskell-prime - Haskell.org

RE: the MPTC Dilemma (please solve)
by Simon Peyton-Jones 01 Mar '06

01 Mar '06

You addressed this to me -- but I'm an advocate for rather conservative extensions whereas you are calling for extensions that go beyond what any current implementation can do. Anyway, there is already a ticket for overlapping instances, I think -- why don't you just add to that. If you send me Wiki-marked-up text I'll gladly paste it in for you. Simon | -----Original Message----- | From: Claus Reinke [mailto:claus.reinke@talk21.com] | Sent: 25 February 2006 15:33 | To: Simon Peyton-Jones | Cc: haskell-prime(a)haskell.org | Subject: Re: the MPTC Dilemma (please solve) | | | Is the behaviour of GHC with -fallow-undecidable-instances (and | | -fcontext-stack) well-understood and specifiable? | >I would not say that it's well-specified, no. | | to start improving that situation, could we please have a task ticket | for "document differences in unconstrained instance handling", then | ask everyone to attach source examples showing such differences? | [can guests attach code to task tickets?] | | the hope being, of course, that implementations nominally providing | the same feature will eventually converge on providing the same | interpretation of all programs using that feature. | | an example of the current oddities (at least they seem odd to me;): | both hugs and ghc claim to resolve overlapping instances in favour | of the most specific instance declaration. both claim that functional | dependencies uniquely determine the range types from the domain | types. but they do not agree on which programs to accept when | we try to combine best-match with FDs. | | I've already given an example where ghc allows me to define | record selection, while hugs complains that the overlap violates | the FDs. | | I reported that as a hugs bug, because I think the best-match | resolution of overlaps should ensure that the FD violation cannot | happen, so the code should be valid. there are different ways to | interpret FDs (something to check, or something to use), but it | seemed that ghc was doing the right thing there. thread start: | | http://www.haskell.org//pipermail/hugs-bugs/2006-February/001560.html | | but after further experimentation, I'm not longer sure that ghc | is doing the right thing for the right reasons. here is a tiny example | of one of the disagreements: | | {- ghc ok | hugs "Instance is more general than a dependency allows" -} | | class C a b | a -> b | instance C a b | | so what is ghc doing there? is it going to guarantee that b will | always be uniquely determined? | | {- ghc ok | hugs "Instance is more general than a dependency allows" -} | | class C b | -> b where c :: b | instance C b where c = error "b" | | safely m = m `CE.catch` print | main = do | safely $ print $ (c::Int) | safely $ print $ (c::Bool) | safely $ print [id,c] | | oh, apparently not. unless b is uniquely determined to be universally | quantified, and the instantiations happen "after" instance selection. | | {- ghc ok | hugs "Instance is more general than a dependency allows" -} | | class C b | -> b where c :: b | instance C b where c = error "b" | | class D a where d :: a -> String | instance C a => D a where d a = "a" | instance C Int => D Int where d a = "Int" | | -- try at ghci prompt: (d 1,d (1::Int)) | -- gives: ("a","Int") | | so that parameter of C isn't all that unique. at least not long enough | to influence instance selection in D. | | comments? | | cheers, | claus

3 2

RE: Export lists in modules
by Simon Peyton-Jones 01 Mar '06

01 Mar '06

These days, hs-boot files are pretty close to source files, with masses of stuff omitted. However, you must process the import declarations of the hs-boot file to figure out the name spaces involved. In the original source file, you can't process the import declarations because those modules have not been compiled yet. It's not clear which ones to omit. Similarly in the body of the source file, there are lots of references to things in imported modules, but those imported modules have not been compiled yet. You could imagine a) compiling recursive groups "all at once" b) somehow magically filtering the source file to omit anything undefined, leaving only defined stuff..... which ought to be enough to tie the knot. But GHC currently requires the programmer to perform (b) manually. Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Ben Rudiak-Gould | Sent: 23 February 2006 21:26 | To: haskell-prime(a)haskell.org | Subject: Re: Export lists in modules | | Malcolm Wallace wrote: | > An explicit interface would be useful for many purposes besides | > machine-checked documentation. For instance, it could be used to | > eliminate the hs-boot or hi-boot files used by some compilers when | > dealing with recursive modules. | | Why *does* ghc require hs-boot files? What can be gleaned from an hs-boot | file that couldn't be expressed in the corresponding hs file? For example, | why doesn't ghc simply require that at least one module in a recursive group | contain an explicit export list mentioning only explicitly typed symbols? | | -- Ben | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

4 3

RE: realToFrac issues
by Simon Marlow 01 Mar '06

01 Mar '06

On 28 February 2006 18:42, Jacques Carette wrote: > What *problem* are you actually trying to solve here? The problem that 'realToFrac (0/0 :: Float) :: Double' doesn't give you NaN, and similarly for the other special float values. > If it is > "conversion between floating point types", then there are other > solutions that do not need to ``pollute'' exact arithmetic. I did not > see any tickets on this -- did I miss it/them? This is one issue > where I should go and contribute, as I've been part of a team that > has done just this to a programming language before, so at least I > can claim to know the pitfalls to avoid! Please go ahead and create a ticket. I don't claim to know a great deal about floating point, but Cale Gibbard's suggestion (use encodeFloat.decodeFloat) looks reasonable to me. I have an old item on my GHC ToDo list that says "make encodeFloat.decodeFloat work for NaN" :-) Cheers, Simon

1 0

RE: the MPTC Dilemma (please solve)
by Simon Peyton-Jones 01 Mar '06

01 Mar '06

| >You addressed this to me -- but I'm an advocate for rather conservative | >extensions whereas you are calling for extensions that go beyond what | >any current implementation can do. | | generally, that may be true,-) but in this specific case, I was just asking | for an effort to document the differences in current handling of extended | Haskell in hugs and ghc, by collecting test cases such as those I included. Collecting test cases is indeed useful. But since it is apparently well beyond Haskell', you probably don't want to tangle it up with the Haskell' web site. In that case, a plausible place to collect them would be the GHC user documentation wiki http://haskell.org/haskellwiki/GHC:Documentation. At the bottom is "Collaborative documentation" and you could add a new page for "Overlapping instances and functional dependencies" or whatever. It's all entirely world-writeable. I know you want to describe the differences between GHC and Hugs, but this seems as good a place as any to do so. thanks Simon

1 0

RE: the MPTC Dilemma (please solve)
by Simon Peyton-Jones 28 Feb '06

28 Feb '06

With help from Martin Sulzmann and Ross Paterson, GHC (HEAD) now implements a richer form of functional dependencies than Mark Jones's version, but still decidable etc. The rules for what must appear in the context of an instance declaration are also relaxed. The specification is here: http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions .html#instance-decls I think this is a step forward, and a serious candidate for Haskell'. I think that if you stick to these rules, everything is nailed down as Martin so rightly says it should be. And I am not sure we can go much further. Of course -fallow-undecidable-instances still lifts all restrictions, and then all bets are off. Many thanks to Ross and Martin. You can try it out by downloading a GHC snapshot (or by building from source). Simon | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | isaac jones | Sent: 11 February 2006 01:29 | To: haskell-prime(a)haskell.org | Subject: the MPTC Dilemma (please solve) | | I've created a wiki page and a ticket to record solutions to what I'm | calling the "Multi Parameter Type Class Dilemma". It's summarized | thusly: | | MultiParamTypeClasses are very useful, but mostly in the context of | FunctionalDependencies. They are particularly used in the monad | transformer library found in fptools. The dilemma is that functional | dependencies are "very, very tricky" (spj). AssociatedTypes are | promising but unproven. Without a solution, Haskell' will be somewhat | obsolete before it gets off the ground. | | I've proposed a few solutions. Please help to discover more solutions | and/or put them on the ticket/wiki. | | Wiki page: | http://hackage.haskell.org/trac/haskell-prime/ticket/90 | | Ticket: | http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClasses Dilemma | | | peace, | | isaac | | | | -- | isaac jones <ijones(a)galois.com> | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

4 3

Re: [Haskell'-private] pragmas and annotations (RE: the record system)
by Malcolm Wallace 28 Feb '06

28 Feb '06

"Simon Marlow" <simonmar(a)microsoft.com> wrote: > How does ENCODING work for a UTF-16 file, for example? > We don't know the file is UTF-16 until we read the ENCODING pragma, > and we can't read the ENCODING pragma because it's in UTF-16. Use the same type of heuristic as XML uses (for instance). * If the first three bytes of the file are "{-#", then keep reading in ASCII/Latin-1/whatever until you discover an ENCODING decl (or not). * If the first six bytes of the file are one of the two possible UTF-16 representations of "{-#", then assume UTF-16 with that byte-encoding until we find the ENCODING decl. (A missing decl in this case would be an error.) * If the first twelve bytes of the file are a UCS-4 representation of "{-#" then ... you get the picture. * For UTF-16 and UCS-4 variations, you must also permit the file to begin with an optional byte-order mark (two or four bytes). * Otherwise, there is no ENCODING pragma, so assume the implementation default of {ASCII, Latin-1, UTF-8, ...}. I know it's pretty horrible, but it seems to work in practice for the XML people. In practice, the ENCODING decl is most needed for those that have ASCII as a subset - one could argue that the heuristic tells you the UTF-16 and UCS-4 variations without needing a pragma. (But then, how would you guarantee that the first three characters in the file must be "{-#" ?) Regards, Malcolm

3 2

realToFrac issues
by John Meacham 28 Feb '06

28 Feb '06

I am not sure if this has been brought up for haskell-prime or not, but a while ago someone noticed that 'realToFrac' as specified in the report can't propagate NaN or infinity values properly since it goes through a Rational intermediate stage. this has the odd effect in ghc of making such conversions only work when optimization is used so the RULES turning Float<->Double conversion into their C counterparts fire. The proposed solution was to add NaN, +Infinity, and -Infinity to rational with the representations 0 :% 0, 1 :% 0, and -1 :% 0 respectively. Seems straightforward, (and generally useful) but we should make sure not to forget it for haskell-prime. John -- John Meacham - ⑆repetae.net⑆john⑈

5 7

RE: Export lists in modules
by Simon Marlow 28 Feb '06

28 Feb '06

On 28 February 2006 13:37, Lennart Augustsson wrote: > John Meacham wrote: >> >> I mean, even a for loop in haskell is done as >> mapM action [0..10] >> >> I'd say _most_ uses of lists are deforested away because they are >> used to express control and dataflow and arn't actually used as >> persistant structures. > > Yes, they are optimized away when ghc actually works. :) At the > moment this seems to be broken (try length[1..n] in 6.4.1). Known bug (well, known since a few weeks ago at least). http://cvs.haskell.org/trac/ghc/ticket/683 Cheers, Simon

1 0

RE: the MPTC Dilemma (please solve)
by Simon Peyton-Jones 28 Feb '06

28 Feb '06

I would not say that it's well-specified, no. What we do know is this: GHC may loop if you use -fallow-undecidable-instances -- but if it terminates, the program is well typed and should not "go wrong" at runtime. S | -----Original Message----- | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Ashley Yakeley | Sent: 21 February 2006 20:13 | To: haskell-prime(a)haskell.org | Subject: Re: the MPTC Dilemma (please solve) | | Simon Peyton-Jones wrote: | | > Of course -fallow-undecidable-instances still lifts all restrictions, | > and then all bets are off. | | Is the behaviour of GHC with -fallow-undecidable-instances (and | -fcontext-stack) well-understood and specifiable? It is a very useful | option, as you can join (meet?) classes like this: | | class P a | class Q a | | class (P a,Q a) => PQ a | instance (P a,Q a) => PQ a | | -- | Ashley Yakeley | | _______________________________________________ | Haskell-prime mailing list | Haskell-prime(a)haskell.org | http://haskell.org/mailman/listinfo/haskell-prime

3 5

Re: public/private module sections (was: Haskell-prime Digest, Vol 2, Issue 58)
by Benjamin Franksen 27 Feb '06

27 Feb '06

On Friday 24 February 2006 16:38, Bulat Ziganshin wrote: > i personally prefer to have > public/private modifiers on each function and gather interface > documentation by tools like haddock Me too. Ben

7 6