[Haskell] why don't we have const Ptrs?
Sven.Panne at aedion.de
Thu Nov 3 03:35:08 EST 2005
Am Mittwoch, 2. November 2005 15:02 schrieb David Roundy:
> [...] Why is it that in C++ I can write
> void strcpy(char *dest, const char *src);
> but in Haskell I must import this function as
> > foreign import ccall unsafe "static string.h strcpy"
> > strcpy :: Ptr CChar -> Ptr CChar -> IO ()
> and lose that wonderful information that the function doesn't modify the
> contents of its second argument? [...]
This topic has been raised several times when the FFI was in its design phase,
(you might find some mail threads in ffi at haskell.org), but there was no real
enthusiasm at that time to do something about it. Actually I see 2 problems
* Tell the FFI that the pointer is "const", so we don't get that annoying
warnings from the C compiler anymore.
* Ensure that a pointer is actually used "the const way" in Haskell.
Personally I think that the first problem is more severe and should be tackled
first. But given the widespread use of the FFI nowadays, it is very important
that we don't break existing code and delay the nice and correct soution
until Haskell2 (or whatever it will be called) is out.
I would even be happy if something simple & ugly like
data Const p = Const p -- somewhere in a library
foreign import ccall unsafe "static string.h strcpy"
strcpy :: Ptr CChar -> Const (Ptr CChar) -> IO ()
would be officially sanctioned. Pro: Backwards compatibility. Cons: The caller
has to wrap the pointer explicitly (a small burden, IMHO); vague semantics
(what does "Const (Ptr (Const (Const a)))" or "Const Int" mean?); no
"const-checking" on the Haskell side.
More information about the Haskell