Re: instance Functor Set, was: Re: Export lists in modules
Jim Apple wrote: class MyMap f a b where myMap :: (a - b) - f a - f b instance (Functor f) = MyMap f a b where myMap = fmap instance (Ord a, Ord b) = MyMap Data.Set.Set a b where myMap = Data.Set.map OK (I guess). But my point was that I want to use do notation for Sets (in fact, for any kind of collection) so I'd need the original Functor and Monad. I couldn't use ghc's Rebindable Syntax feature because the types for (=) would not match? http://www.haskell.org/ghc/docs/6.4/html/users_guide/syntax-extns.html#rebindable-syntax Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: relaxed instance rules spec (was: the MPTC Dilemma (please solve))
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:[EMAIL PROTECTED]
| Sent: 28 February 2006 19:54
| To: Simon Peyton-Jones; haskell-prime@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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: Keep the present Haskell record system!
Ross Paterson [EMAIL PROTECTED] wrote: On Wed, Mar 01, 2006 at 08:26:14AM +, Henrik Nilsson wrote: I'm increasingly convinced that the records should be left alone for Haskell', possibly modulo some minor tweaks to polish the system. Yes, no alternative candidate is available (specified, implemented, used). Well, there _are_ some alternatives that have been specified and implemented e.g. TREX in Hugs, and experimental languages like Daan Leijen's Morrow. But the main reason I can see for there being little use of these candidates, is that they are not compatible with current Haskell. Thus, although I agree that none is ready for inclusion in Haskell-prime, I think we do need some mechanism for experimental records to be tried out in real Haskell implementations before the Haskell-double-prime committee starts its work. Perhaps, taking the extensions-layering idea, we could say that the current named-fields are encapsulated as an extension that is part of the standard. Implementations could then introduce a flag to switch off this particular extension (current records) in conjunction with flags to switch on experimental replacements. This would give a certain flexibility for users to play with different systems, and the breaking of compatibility would be explicitly notated, either by the build options, or using a proposal like ticket #94. My suggestion is that we separate out everything from the Report to do with named-field records into something like a self-contained addendum. Whilst still an official part of the language standard, it might also be marked as a possibility for future removal. This would make it clear what parts of the language could be changed (or re-used without conflict) in an alternative records system. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: realToFrac issues
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: instance Functor Set, was: Re: Export lists in modules
On 3/1/06, Johannes Waldmann [EMAIL PROTECTED] wrote: But my point was that I want to use do notation for Sets (in fact, for any kind of collection) so I'd need the original Functor and Monad. I understand this for Monad. Why not just redefine Functor, Oleg-style? I couldn't use ghc's Rebindable Syntax feature because the types for (=) would not match? http://www.haskell.org/ghc/docs/6.4/html/users_guide/syntax-extns.html#rebindable-syntax Good news, everyone! http://www.haskell.org/ghc/dist/current/docs/users_guide/syntax-extns.html#rebindable-syntax That looks good to me! Jim ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: overlapping instances and constraints
Niklas Broberg wrote: Ben Rudiak-Gould wrote: Are there uses of overlapping instances for which this isn't flexible enough? Certainly! Hmm... well, what about at least permitting intra-module overlap in Haskell' (and in GHC without -foverlapping-instances)? It's good enough for many things, and it's relatively well-behaved. instance (Show a) = IsXML a where toXML = toXML . show The intention of the latter is to be a default instance unless another instance is specified. I can see how this is useful, but I'm surprised that it's robust. None of the extensions people have suggested to avoid overlap would help here, clearly. Are there uses of overlapping instances for which the single-module restriction isn't flexible enough, but extensions that avoid overlap are flexible enough? -- Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: overlapping instances and constraints
Ben Rudiak-Gould wrote: I think all of these problems would go away if overlap was permitted within a module but forbidden across modules. Are there uses of overlapping instances for which this isn't flexible enough? I dislike this on principle. I like the idea that modules can be refactored easily. But I'm not a big fan of overlapping instances anyway, and don't turn on the option. This makes it easier to reason about instances, as they always apply to their complete domains. I'm much more interested in allowing non-overlapping instances such as: class C a instance C Bool instance (Num a) = C a However, I'm aware this is hard for the type-checker. In general, I think there's a consensus on what the type-checker should allow in a perfect world (assuming one has made a decision on whether to allow overlapping instances etc.). It seems the problem is how much of perfection can be implemented. It might be worth collecting examples of things that don't compile but should on a HaskellWiki page. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: the MPTC Dilemma (please solve)
On Tue, Feb 28, 2006 at 07:12:28PM -, Claus Reinke wrote: Anyway, there is already a ticket for overlapping instances, I think -- why don't you just add to that. that might work. apart from the fact that I really, really hate the braindead wiki markup processor, especially when editing through that tiny ticket change field instead of loading up text. I went through that experience once, when Isaac suggested the same for my labels proposal - I don't want to have to do that again. MozEX is your friend: http://mozex.mozdev.org/ it lets you click on any text field on the web and say 'edit in vim' (or whatever editor you choose) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: relaxed instance rules spec (was: the MPTC Dilemma (please solve))
On Thu, Mar 02, 2006 at 03:53:45AM -, Claus Reinke wrote: - Mul recurses down a type in its second parameter - types in Haskell are finite - there is a non-terminating Mul inference the problem is that we have somehow conjured up an infinite type for Mul to recurse on without end! Normally, such infinite types are ruled out by occurs-checks (unless you are working with Prolog III;-), so someone forgot to do that here. why? where? how? Polymorphic recursion allows the construction of infinite types if I understand what you mean. if you are clever (or unlucky) you can get jhcs middle end to go into an infinite loop by using them. -- an infinite binary tree data Bin a = Bin a (Bin (a,a)) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
