Re: [Pika-dev] What's on my plate for Pika...

[Matthew Dempsky]

Andreas Rottmann <address@hidden> writes:

> Sure. One area where the Guile and Pika FFI's will differ big time is
> error handling. From what I get out of the Pika notes, errors are
> returned as return values, whereas Guile uses non-returning functions
> (that longjmp to the handler). I would be interested how the "Plan"
> for errors looks like; I didn't find much about it in the notes. I
> think it might be a good idea to have a look at SRFI-35 and keep that
> in the back of the head while designing the error handling mechanism.
>
> Error/Exception handling and unifiying Guile and Pika FFI is an area
> I'd be interested in getting my hands dirty; however, I don't quite
> know where errors fit into the big picture/plan.

Well, my initial reaction was that most errors that can be raised
could be detected ahead of time in the FFI wrapper level so while
Guile's native scm_car may just use longjmp when the argument isn't a
pair, we can avoid that by testing before hand and then just
returning.

However, like I said earlier, both Pika and Guile use the scm_ prefix
for functions so I need to find some hack to work around that... maybe
write the Pika FFI wrapper for Guile to define instead functions like:

pika-ffi.c:
  +-------------------------------------
  | [etc...]
  |
  | t_scm_error
  | pika_car (t_scm_word * answer,
  |           t_scm_arena arena,
  |           t_scm_word * value)
  | {
  |   if (!scm_pair_p (*value))
  |     return scm_err_wta1;
  | 
  |   *answer = scm_car (*value);
  |   return 0;
  | }
  |
  | [etc...]
  +-------------------------------------

pika-ffi.h:
  +-------------------------------------
  | typedef SCM t_scm_word;
  | 
  | [etc...]
  |
  | t_scm_error pika_car (t_scm_word * answer,
  |                       t_scm_arena arena,
  |                       t_scm_word * value);
  | 
  | [etc...]
  | 
  | #define scm_car pika_car
  | 
  | [etc...]
  +-------------------------------------

Thoughts?

-jivera