Hi all, I have a couple of questions about Green Card and exceptions. I am interfaceing to the GSL to get access to a few functions, and eventually interface all of the special functions to Haskell. And unlike my DSP library, and am trying to get it right the first time. :) Below is a Green Card interface to one of the functions. %fun airy_Ai_e :: Double -> (Double, Double) %call (double x) %code int rc; % double val; % double err; % gsl_sf_result result; % rc = gsl_sf_airy_Ai_e(x, GSL_PREC_DOUBLE, &result); % val = result.val; % err = result.err; %result (double val, double err) This definition works, but it ignores the return code from the library function. The various return codes are from an enum defined in a header file. I would like to throw a Haskell exception (one of the ArithExceptions defined in Control.Exception) depending on the value of "rc". Do I need to create a new DIS for the return values (which are an enum defined in a header), change the function to return a triplet (var,err,rc), and then throw the exception in Haskell land? Is there a way I can do this directly from the GC interface? If I have to create a DIS, can this be shared across several modules that all need the same functionality? Thanks. -- Matthew Donadio (m.p.donadio@ieee.org)
On Friday 13 June 2003 3:37 am, Matthew Donadio wrote:
Hi all,
I have a couple of questions about Green Card and exceptions.
[...]
This definition works, but it ignores the return code from the library function. The various return codes are from an enum defined in a header file. I would like to throw a Haskell exception (one of the ArithExceptions defined in Control.Exception) depending on the value of "rc".
The %fail statements (described in the last few paragraphs of http://www.haskell.org/greencard/downloads/greencard-latest/type-sig.html) consist of two C expressions. For example: %fail {f == NULL} {errstring(errno)} The first is a test for failure. The second is an expression which returns a C string. If the test expression fails, the string expression is evaluated and used to generate a UserError.
If I have to create a DIS, can this be shared across several modules that all need the same functionality?
It would be nice to be able to write something like: %fail POSIX_FD(fd) where POSIX_FD is something you defined elsewhere (e.g., it might test if its file-descriptor argument is -1). GreenCard can't do this. It would also be nice to be able to generate a different error instead of UserError. We'd need to specify the type and the exception constructor so a plausible syntax would be: %fail {f == NULL} (UserError (string {errstring(errno)})) [Detail: should it be a Haskell98 IOError constructor or a non-standard but widely implemented exception constructor? Should it be a function or a constuctor?] Again, GreenCard can't do that. As GreenCard maintainer, I've got to ask: - How many users of GreenCard are still out there? - Are you developing new libraries or just maintaining the ones you've got? - Is there a demand for new features? -- Alastair Reid
Alastair Reid wrote:
The %fail statements (described in the last few paragraphs of http://www.haskell.org/greencard/downloads/greencard-latest/type-sig.html) consist of two C expressions. For example:
%fail {f == NULL} {errstring(errno)}
The first is a test for failure. The second is an expression which returns a C string.
If the test expression fails, the string expression is evaluated and used to generate a UserError.
OK, I think I misread the manual. Sect 7.6 talks about functions with side effects, so I assumed that the function had to have type (IO a) to use %fail.
It would also be nice to be able to generate a different error instead of UserError. We'd need to specify the type and the exception constructor so a plausible syntax would be:
%fail {f == NULL} (UserError (string {errstring(errno)}))
[Detail: should it be a Haskell98 IOError constructor or a non-standard but widely implemented exception constructor? Should it be a function or a constuctor?]
In the case of what I am doing, I'm not sure if IOError really make sense philosophically. The failures I need are underflow, overflow, loss of precision, etc. Since IOError is a type synonym for IOException, then perhaps accepting an Exception constructor is appropriate. To keep compatibility with old libraries it may be wise to keep %fail as is, and have a new directive %throw that accepts an Exception constructor, and uses either throw or throwIO. On the other hand, now that I know that I can use %fail with pure functions, I can make that work.
As GreenCard maintainer, I've got to ask: - How many users of GreenCard are still out there?
New GreenCard user. In my case, I need access to C land for typedefs and macros. I could write my own stubs, but GreenCard saves me this step.
- Are you developing new libraries or just maintaining the ones you've got?
New library.
- Is there a demand for new features?
A more generic %fail mechanism? Thanks for the response. -- Matthew Donadio (m.p.donadio@ieee.org)
participants (2)
-
Alastair Reid -
Matthew Donadio