On May 23, 2006, at 11:13 AM, Jacques Carette wrote:
Bertram Felgenhauer wrote:
Jacques Carette wrote:
Bulat Ziganshin wrote:
malloc :: Storable a => IO (Ptr a)
malloc = doMalloc undefined
where
doMalloc :: Storable b => b -> IO (Ptr b)
doMalloc dummy = mallocBytes (sizeOf dummy)
Is there any reason to not code this as
malloc :: Storable a => IO (Ptr a)
malloc = mallocBytes $ sizeof undefined
What type would the 'undefined' have in this context?
sizeOf has type Storable a => a -> Int -- that doesn't help.
The purpose of doMalloc is to force the type checker to choose
the right type for that 'undefined'.
I still don't quite see it! To my eyes, the type of doMalloc and
the type of malloc look exactly "the same", with neither providing
more specificity than the other. Also, the 'undefined' can be of
any type, as long as it is from class Storable. So it is a
placeholder for a dictionary - what else does it need? [Constraint-
typing-wise, it doesn't need anything else, but perhaps the issue
is that I don't understand Haskell's type system quite well enough].
I guess I am also asking "Is there a GOOD reason why the simpler
code can't be used?". Or maybe what I really need is
malloc :: Storable a => IO (Ptr a)
malloc = mallocBytes $ sizeof undefined::a
? That would make sense to me, since in a more general function I
might have 2 instances (Storable a, Storable b) available, and 2
undefineds, and I could not know how to match them up
deterministically in all cases.
I guess I prefer a type annotation over a dummy function that is
there just to force the type checker to believe me. If one has to
force the type checker, may as well do it with a type, not code!
Sure, and there's good reasons to prefer this. It's not Haskell 98,
however. In Haskell 98 type variables in type signatures are not in
scope in the body of the function. Adding the type annotation
(undefined::a) is the same as (undefined::forall a. a) because free
type variables are automatically bound with universal quantifiers.
Obviously, that isn't what you want here. So instead one has to play
games with the type checker to force the right things to unify.
Another thing you'll see sometimes is lazy pattern matching and
'asTypeOf' used to get at type variables inside data types.
GHC has an extension to allow scoped type variables and there's also
a Haskell' ticket for it.
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-
extensions.html#scoped-type-variables
http://hackage.haskell.org/trac/haskell-prime/wiki/ScopedTypeVariables
Rob Dockins
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
-- TMBG
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
