- Haskell-Cafe - Haskell.org

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

19 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 19 Jan '02

19 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

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

19 Jan '02

At 2002-01-18 03:06, Cagdas Ozgenc wrote: >Well can you give examples of some useful functions? I can live without id, >and (.) Well what about [] and 'c'? [] :: [a] 'c' :: Char Not functions, of course. But Haskell definitions are just values: it would be odd if a restriction applied to some values (functions) and not others. -- Ashley Yakeley, Seattle WA

1 0

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

18 Jan '02

At 2002-01-18 00:06, Cagdas Ozgenc wrote: >Why does Haskell let you write functions that are not a part of type class? Well, what classes should such functions as const, id and (.) be members of? const :: a -> b -> a; const x y = x; id :: a -> a; id x = x; (.) :: (b -> c) -> (a -> b) -> (a -> c); (.) f g x = f (g x); >For example instead of > >elem :: Eq a => a -> [a] -> Bool >map :: (a -> b) -> [a] -> [b] > >class Container a where > elem :: Eq b => b -> a b -> Bool > map :: (b -> c) -> a b -> a c > >would define methods that can work on all containers, Actually this would only work on container type-constructors. If you had a type that was some kind of container only of Char, you could not make it an instance of your Container. >and create a discipline to write more reusable and generic functions. There's already a generalised version of map, called fmap, that works on any Functor type. Picking the correct generalisation is often not obvious... -- Ashley Yakeley, Seattle WA

5 4

memoization hints?
by Feuer 18 Jan '02

18 Jan '02

It seems that under some circumstances it might be good for a programmer to be able to tell the implementation not to remember something. In particular, intermediate data structures may be remembered for much longer than they should be. If I am not mistaken, full laziness (which I think ghc uses with -O ?) can make this worse. Would it be beneficial to have some kind of annotations to help deal with this? I don't really know how it would be implemented. Take a standard sort of example: fib n = let f = 0:1:zipWith (+) f (tail f) in f !! n -- code that first calculates fib 1000, then fib 3, fib 4, then does some other stuff I believe that the entire list will be maintained (when compiled with ghc -O) after calculating fib 1000, despite the fact that it will never be used again. If I could say instead fib n = let forget f = 0:1:zipWith (+) f (tail f) in f !! n and somehow get it to forget about f as often as possible (somehow suppressing laziness in this case). I would certainly want to forget about it whenever it goes out of scope, but in this case I would really want to somehow ensure that the list is never held entirely in memory (forgetting it as it is built in f !! n).

1 0

mzero
by Feuer 18 Jan '02

18 Jan '02

Why is mzero in MonadPlus rather than a separate MonadZero class?

1 0

functions not in type classes
by Cagdas Ozgenc 18 Jan '02

18 Jan '02

Greetings. Why does Haskell let you write functions that are not a part of type class? For example instead of elem :: Eq a => a -> [a] -> Bool map :: (a -> b) -> [a] -> [b] class Container a where elem :: Eq b => b -> a b -> Bool map :: (b -> c) -> a b -> a c would define methods that can work on all containers, and create a discipline to write more reusable and generic functions. Thanks

2 1