qforeign-0.62

[Manuel M. T. Chakravarty]

"Marcin 'Qrczak' Kowalczyk" <mk167280 at zodiac.mimuw.edu.pl> wrote,

> On Tue, 28 Nov 2000 malcolm-ffi at cs.york.ac.uk wrote:
> 
> > I think we should use symbolic error codes in Haskell, like the
> > `ENOENT' style in C.  This is for portability, because as you may
> > know, on different operating systems, symbolic names map to different
> > ints. I would hate to see magic numbers like '35' on IRIX but '54' on
> > SunOS appearing in code.
> 
> First of all, in the case of errno I don't see the need of exposing
> particular constans to Haskell programmers. Usually it's enough (and
> necessary) to convert errno to Haskell's exception.

I understand that Malcolm wants to be able to get to the
constants, but

> There are sometimes cases where specific errno values are needed. The
> situation is no different than for other symbolic constants, like F_GETFL.
> There is just a need for a more convenient generic solution than wrapping
> all these values in functions - which is portable but really painful. It
> does not matter if it will be hsc2hs or something different, but it will
> be needed anyway, so we don't have to go a hard way for errno.

I also agree with this.  Hardcoded data types should be
avoided were possible.

> I propose one of the following methods for such cases. First is to use a
> non-abstract type - either a type like CInt which directly corresponds to
> these values in C, or a newtype with the exported constructor, or a type
> with Num instance. Export values known to be present as plain variables.
> Then a programmer which must access a value which was not supported can do
> it.

This sounds reasonable to me.

> The second way is paranoid: do the same but export the type abstractly.
> This is as safe as your solution, but uses the same style of interface
> as non-paranoid solutions, and allows exporting the representation through
> a private module for those who really need it.

I don't really fully understand what you want to say here...

Cheers,
Manuel