[Haskell] why don't we have const Ptrs?

[Sven Panne]

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 
here:

   * 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.

Cheers,
   S.