"Marcin 'Qrczak' Kowalczyk" <mk167280@zodiac.mimuw.edu.pl> wrote,
On Tue, 28 Nov 2000 malcolm-ffi@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