Re: [Haskell-cafe] Can someone explain this typing restriction?
Tim Walkenhorst wrote: I had a feeling this was discussed in "Typing Haskell in Haskell" by Mark Jones, but after a quick skim I can't find it again (I thought it would be in Section 11.6 of his paper). It is, on page 35 (section 11.6.3) of "Typing Haskell in Haskell" by Mark Jones. Now you got me hooked. Where can I find his paper? The link in the Haskell-wiki[1] seems to be dead... I don't know, I've encountered the same problems. Fortunately I have a printed version on my desk. Gerrit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
Gerrit van den Geest wrote: I had a feeling this was discussed in "Typing Haskell in Haskell" by Mark Jones, but after a quick skim I can't find it again (I thought it would be in Section 11.6 of his paper). It is, on page 35 (section 11.6.3) of "Typing Haskell in Haskell" by Mark Jones. Quote: "This is a consequence of a throw-away comment specifying that all explicit type signatures in a binding group must have the same context up to renaming of variables. This is a syntactic restriction that can easily be checked prior to type checking. Our comment here, however, suggest that it is unnecessarily restrictive." I agree with Mark Jones, the Haskell compiler Helium for example doesn't have this restriction. I think this issue is also related to the following Haskell' ticket: http://hackage.haskell.org/trac/haskell-prime/ticket/65 Gerrit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can someone explain this typing restriction?
I had a feeling this was discussed in "Typing Haskell in Haskell" by Mark Jones, but after a quick skim I can't find it again (I thought it would be in Section 11.6 of his paper). It is, on page 35 (section 11.6.3) of "Typing Haskell in Haskell" by Mark Jones. Gerrit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Principal type in Haskell
According to Haskell 98 the principal type of f should be: f :: (Eq a) => a -> a -> Bool. GHC does only perform context-reduction using instance-declarations if there are no type-variables in the type. Because the type in this function is [a], ghc doesn't perform context-reduction. Ghc chooses this strategy because of extensions like overlapping instances, there remains more information in the type of a function to select an instance. For some reason GHC also applies this strategy if one turns of the extensions. Grt william kim wrote: Hi All, I am confused by the notion of principal type in Haskell with type classes. Consider a simple example: f x y = [x] == [y] GHCi yields type f :: (Eq [a]) => a -> a -> Bool. But according to the paper "Type classes: an exploration of the design space", predicate Eq [a] should be reduced to Eq a. Is this reduction performed here? What should be the principal type of f? Thanks. william _ Get an advanced look at the new version of MSN Messenger. http://messenger.msn.com.sg/Beta/Default.aspx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Define combination of type classes?
Another option is to just add the instance: > instance FooBar Char instead of > instance (Foo a, Bar a) => FooBar a Now you don't need any extensions, the disadvantage is that you have to add an instance for each type... There has also been an proposal for type class synonyms: http://repetae.net/john/recent/out/classalias.html Maybe you like it, Gerrit Sean Seefried wrote: On 24/03/2006, at 12:45 PM, Fritz Ruehr wrote: What is the easiest way to name a combination of type classes, i.e., to abbreviate the fact that a certain type is an instance of several classes simultaneously? I have a vague sense that this is do-able, but that I am messing up by trying to use an empty class body as below. So in the code below, I try to use FooBar to abbreviate the conjunction of Foo and Bar. But while f (which uses a FooBar constraint) has a valid definition, it can't be used. On the other hand, g (which uses the long-winded constraint), is both a valid defined and useable. (In a real example, imagine that FooBar names a conjunction of a half dozen things, so that the g-like form really is onerous, whereas the f-like form would be sweet and tidy :) .) Hi Fritz! You only need to do a couple of things to get this working. Add an instance declaration: instance (Foo a, Bar a) => FooBar a But for this to work you need to allow undecidable instances (and - fglasgow-exts). To have this type class synonym trick work you need both the class and instance declaration: class(Foo a, Bar a) => FooBar a instance (Foo a, Bar a) => FooBar a The first ensures that members of class FooBar will inherit the methods of classes Foo and Bar. The second ensures that if there is a Foo and a Bar instance then there will be a FooBar instance. You were lacking this in your code hence the error message: > f 'a' No instance for (FooBar Char) arising from use of `f' at :1:0 Probable fix: add an instance declaration for (FooBar Char) In the definition of `it': it = f 'a' This is a neat trick. I've also used it to reduce onerous contexts. Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type classes
Then you should produce 'some canonical representation for database entries suited for comparison', like Stefan mentioned. For example: > data Entry = forall a. (DatabaseEntry a) => Entry a > > instance DatabaseEntry Entry where >entryLabel (Entry e) = entryLabel e >formatEntry (Entry e) = formatEntry e >compareEntries (Entry x) (Entry y) = compare (entryLabel x) (entryLabel y) Gerrit Max Vasin wrote: "Geest," == Geest, G van den <[EMAIL PROTECTED]> writes: Geest,> I suppose you want to define compareEntries like this: compareEntries (Entry x) (Entry y) = compareEntries x y Geest,> An option is to just implement it the following way Geest,> (Haskell98!): class DatabaseEntry e where entryLabel :: e -> String formatEntry :: e -> String compareEntries :: e -> e -> Ordering data Entry a = Entry a No. I don't want that. The database parsing function returns Map.Map String Entry but entries can of different types (and these type vary over styles). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems instancing a class
Mark Mark Jones has (some time ago) also written a very detailed e-mail about this topic: http://www.haskell.org/pipermail/haskell/2000-October/006128.html Grt "type" introduce a type synonym, and Haskell98 forbids these in instances, so GHC complains. GHC also lifts this restriction when invoked with -fglasgow-exts . http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#type-synonyms Flexible Instances will probably be added to HaskellPrime: http://hackage.haskell.org/trac/haskell-prime/wiki/FlexibleInstances This page: http://cvs.haskell.org/Hugs/pages/users_guide/class-extensions.html#FLEXIBLE-INSTANCES says that ultimately you would turn the type language pretty much into Prolog (which would allow more expressive power---and less inconvenience as we both would like--but make general type checking undecidable). Instead they do a more conservative extension with a fixed depth of constraints it will check so the compiler will terminate. Jared. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
