Hello all, I was thinking this morning as I lay on the floor (where I sleep) about static typechecking, and how much more wonderful Haskell is than any other language, when it occurred to me that when working with pointers, Haskell actually has *less* static typechecking than C or C++. It was a very disturbing thought, so much so that I was almost compelled to arise early to place this question before this learned audience. 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? One could pretty easily create a ConstPtr type which one could peek into, but not poke to, but then you'd have to explicitely convert a Ptr into a ConstPtr when passing it as an argument. That feels a bit silly. One could get around this by introducing a class to get around this
class ReadablePtr p where peek :: p a -> IO a peekOff ...
and then make both Ptr and ConstPtr instances of this class, but this still seems like a very hackish solution. Moreover, I'd like to be able to have const objects quite apart from Ptrs, such as a const Handle, which I can read from, but cannot write to, or a const IORef--and we wouldn't want to leave out const ForeignPtrs. Of course, even reading affects a Handle's internal state, so one would need to be explicit about what "const" indicates. But it seems to me that in the IO world there are a whole slew of "things that refer to other things" which could all be grouped together. And a "const" attribute ought to be derived, so that if I create a data type
data FooPtr = FooPtr String (Ptr Foo)
one should ideally be able to automatically understand that a const FooPtr holds a const (Ptr Foo). One could go further, at least when dealing with Ptrs, and create a way of handling "restricted" pointers--which we could interpret as a const pointer to an object that cannot be changed by anyone else either. One could safely create restricted pointers with a function of the type
mallocRestrictedPtr :: (Ptr a -> IO ()) -> RestrictedPtr a
which would allow one to ensure at the typechecking level that RestrictedPtrs point to memory that cannot be modified. There's still some unstafety involved, in that you could read out of bounds, but you would know that apart from that possibility the contents of a RestrictedPtr truly will never change. So my question is, how would one implement such an "annotation" extension? I'd like to be able to pass a (Ptr a) as a (Const (Ptr a)) without an explicit typecast, since the Const really isn't changing the type of the pointer, it's just marking it as one that can't be modified. A function that accepts a (Const (Ptr a)) should also accept a (Restricted (Ptr a))--but Restricted pointers are really just pudding, as they only differ from Const pointers in what optimizations are allowed. On the other hand, it's not just compiler optimizations that they would allow, but also user-code optimizations, which could be much more useful. They also have the advantage of making certain unsafe functions safe. The hard part seems to be the lack of a conversion. One could quite easily implement a
data Const a = Const a -- this constructor is *not exported* toConst :: x -> Const x unsafeAccessConst :: Const x -> x
peek :: Const (Ptr a) -> IO a peekOff ...
etc, and everything would work fine, except that you'd always need to explicitely convert from Ptr to Const Ptr. Perhaps one could make Const be a class as well as a data type:
class (Const a) x where toConst :: x -> Const a instance (Const x) x where toConst = Const instance (Const x) (Const x) where toConst = id
and then one could write code like
peek :: Const (cp a) => cp a -> IO a
which would move the typecasting burden out of the calling function and into the function that accepts a const argument. Perhaps this would be sufficient, as many data types have only a limited number of "primitive const" functions, and all the other "const" functions wouldn't actually need to call toConst. What this doesn't allow is deriving of constness, so that a Const ForeignPtr would automatically hold a Const Ptr. This whole class+data type scheme seems like it might be useful, but is pretty ugly. Is there a better way this could be done? Might one be able to extend the language so that one could add "attribute" such as Const to data type without changing the the type itself (which would be analogous to what one does in C/C++)? -- David Roundy http://www.darcs.net