- Haskell-Cafe - Haskell.org

Re: Ambiguous types
by Ashley Yakeley 21 Jan '02

21 Jan '02

At 2002-01-21 02:19, Janis Voigtlaender wrote: >The problem is >that for some instance A1 of Ord, l might be an empty list, whereas for >some other instance A2 of Ord, l might be nonempty. Right. I understand now. -- Ashley Yakeley, Seattle WA

1 0

Re: Ambiguous types
by Ashley Yakeley 21 Jan '02

21 Jan '02

I'm quite convinced the Haskell implementations are correct to complain, I just don't understand it intuitively. Anyway, here's an even simpler example: compiles fine: ordnull :: forall a. (Ord a) => [a] -> Bool ordnull = null ordtrue :: (forall a. (Ord a) => [a]) -> Bool ordtrue = const True gives type error: ordnull :: (forall a. (Ord a) => [a]) -> Bool ordnull = null -- Ashley Yakeley, Seattle WA

2 1

Re: Ambiguous types
by Ashley Yakeley 21 Jan '02

21 Jan '02

At 2002-01-21 02:04, Koen Claessen wrote: >But from the type you give the function `emptyList': > > emptyList :: Ord a => [a] > >we cannot derive that the type of the function `emptyList' >does not matter for its result. So, the type checker will >complain. That's it! Consider: -- class C a where emptyList :: [a] instance C Int where emptyList = [] instance C Char where emptyList = "Hello" -- Clearly emptyList has type "(C a) => [a]"... So in the original example, (validActions actor) cannot be compared to the empty list because its value may depend on the type of u. This would not be possible if there were no (Action u) context. -- Ashley Yakeley, Seattle WA

1 0

Re: Ambiguous types
by Ashley Yakeley 21 Jan '02

21 Jan '02

At 2002-01-21 01:15, Koen Claessen wrote: > | But this gives an error: > | > | emptyList :: (Ord a) => [a] > | emptyList = [] > | > | isempty :: Bool > | isempty = null emptyList > >Here is another (very similar) case: > > emptyList :: [a] > emptyList = [] > > showEmptyList :: String > showEmptyList = show emptyList >Now, you might argue that the type error resulting from this >program is too restrictive, since the empty list can always >be shown as: "[]". Of course not, show doesn't know how to show things of arbitrary type [a]. But null is supposed to work on _any_ list. And just from the type of emptyList, Haskell knows that it is a list of something. -- Ashley Yakeley, Seattle WA

2 1

Re: Ambiguous types
by Koen Claessen 21 Jan '02

21 Jan '02

(moved reply to haskell-cafe) Ashley Yakeley wrote: | But this gives an error: | | emptyList :: (Ord a) => [a] | emptyList = [] | | isempty :: Bool | isempty = null emptyList Here is another (very similar) case: emptyList :: [a] emptyList = [] showEmptyList :: String showEmptyList = show emptyList Now, you might argue that the type error resulting from this program is too restrictive, since the empty list can always be shown as: "[]". But this is not true for all types, look at the way the empty *string* is shown. I.e. changing the type of `emptyList' in this example changes the behavior of `showEmptyList'. The compiler does not know what type to choose, and thus gives a type error. /Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 mailto:koen@cs.chalmers.se ----------------------------------------------------- Chalmers University of Technology, Gothenburg, Sweden

1 0

Re: [Fwd: Re: type class VS struct/functor]
by Ashley Yakeley 20 Jan '02

20 Jan '02

At 2002-01-18 18:59, Ahn Ki-yung wrote: >Each of these Set types takes a string, but the membership test is >different. This is an annoying case in Haskell, because you can make a >String a member of the Eq typeclass in only one way. Your example seemed to translate into Haskell quite straightforwardly... module FunctorTest where { import Char; lowercase = fmap toLower; data EQ' t = EQ' { eq :: t -> t -> Bool }; data SET elt set = SET { empty :: set, add :: elt -> set -> set, mem :: elt -> set -> Bool }; fSet :: EQ' t -> SET t [t]; fSet mEq = SET { empty = [], add = \elt set -> elt:set, mem = let { mm elt [] = False; mm elt (x:xs) = if eq mEq x elt then True else mm elt xs; } in mm }; sensitiveCase :: EQ' String; sensitiveCase = EQ' { eq = \s s' -> s == s' }; insensitiveCase :: EQ' String; insensitiveCase = EQ' { eq = \s s' -> (lowercase s) == (lowercase s') }; sensitiveSet = fSet(sensitiveCase); insensitiveSet = fSet(insensitiveCase); } -- Ashley Yakeley, Seattle WA

1 0

schrist@gmx.net
by c-schnell＠t-online.de 20 Jan '02

20 Jan '02

Please add me to the mailinglist.

1 0

[Fwd: Re: type class VS struct/functor]
by Ahn Ki-yung 19 Jan '02

19 Jan '02

Hmm ... How do you solve this in Haskell ? -------- Original Message -------- Subject: Re: type class VS struct/functor Date: Sat, 19 Jan 2002 01:34:32 GMT From: neelk(a)alum.mit.edu (Neelakantan Krishnaswami) Reply-To: neelk(a)alum.mit.edu Organization: ATT Broadband Newsgroups: comp.lang.functional References: <3C48C86E.9282BE00(a)bawi.org> On Sat, 19 Jan 2002 10:14:22 +0900, =?EUC-KR?B?vsix4r+1?= <kyagrd(a)bawi.org> wrote: > > What does ML struct/functor have anything better than type classes ? > For the user type classes feels like implicit functor istantiations > to specific sturucture, and struct/functor seems just bugglling the > user to do more typing which can be automated by using type classes. The advantage of functors shows up when you need to have multiple implementations of a module for a type. For instance, suppose you want to implement a set, and you write the functors (OCaml below): module type EQ = sig type t val eq : t -> t -> bool end module type SET = sig type elt type set val empty : set val add : elt -> set -> set val mem : elt -> set -> bool end module Set(Eq : EQ) : SET with type elt = Eq.t = struct type elt = Eq.t type set = elt list let empty = [] let add elt set = elt :: set let rec mem elt set = match set with | [] -> false | x :: xs -> if Eq.eq x elt then true else mem elt xs end Now, suppose you want two kinds of sets of string, one of which is case-sensitive and one of which is not. You can easily do this with functors like so module SensitiveCase = struct type t = string let eq s s' = (s = s') end module InsensitiveCase = struct type t = string let eq s s' = (String.lowercase s) = (String.lowercase s') end module SensitiveSet = Set(SensitiveCase) module InsensitiveSet = Set(InsensitiveCase) Each of these Set types takes a string, but the membership test is different. This is an annoying case in Haskell, because you can make a String a member of the Eq typeclass in only one way. However, I think it's true that typeclasses are less verbose in the common case. Personally, I want a language with both typeclasses and functors, so that I can use either as the problem requires. Neel

1 0

Re: functions not in type classes
by Ashley Yakeley 19 Jan '02

19 Jan '02

At 2002-01-18 03:06, Cagdas Ozgenc wrote: >Same story, you shouldn't have had a Container of Char only in the first >place. Well, what about a file-handle? Not necessarily exactly a Container (though it might be), but it's always "of Char", or better yet, "of Word8". You could make a generalised file-handle to be of anything, but your read and write functions would necessarily have to be restricted. For instance, given this: class Stream1 c where read :: c a -> Integer -> IO [a] write :: c a -> [a] -> IO () data FileHandle1 a = ... fileRead :: FileHandle1 Word8 -> Integer -> IO [Word8] fileWrite :: FileHandle1 Word8 -> [Word8] -> IO () ...you cannot make FileHandle1 an instance of Stream1. However, you could do this: class Stream2 s a | s -> a where read :: s -> Integer -> IO [a] write :: s -> [a] -> IO () data FileHandle2 = ... fileRead :: FileHandle2 -> Integer -> IO [Word8] fileWrite :: FileHandle2 -> [Word8] -> IO () instance Stream2 FileHandle2 Word8 where read = fileRead write = fileWrite -- Ashley Yakeley, Seattle WA

1 0

Re: functions not in type classes
by Ashley Yakeley 19 Jan '02

19 Jan '02

At 2002-01-18 03:53, Cagdas Ozgenc wrote: >You shouldn't be using multi paramater type classes in place of type >constructors. Yes you should, it's more general. > Then you will have the ambiguity problems that you mention on >you web site. That's what fundeps are for... > Multi parameter type classes have the benefit of using multi >dispatch based on two non related types. Or two related types, if you prefer. -- Ashley Yakeley, Seattle WA

1 0