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!
Jacques
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
