Re: thanks

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Miroslav Silovic <silovic@zesoi.fer.hr> writes:

> Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> 
> > Browsing lily sources reveals calls to scm_assoc, scm_assoc_set_x,
> > scm_reverse ,scm_mkstrpor, scm_ftell, scm_eval_x, scm_read,
> > scm_fill_input, scm_puts, scm_unprotect_object, scm_protect_object,
> > and lots more. I don't think the gh_ interface is rich enough for my
> > purposes, and frankly, I still don't know what it is for exactly.
> 
> This is one of the interesting things with Guile. It's just too
> tempting to use guile's infrastructure (datatypes, gc, pointer
> abstraction) in your C code. I don't think there's anything bad about
> it - guile beats crap out of glib (the only other generic
> datastructure lib I know of) for ease of use, mainly because of GC,
> and I use guile code all over SART - my guess would be that it cut the
> size of C portion of the system to about 1/2 of what it'd be if I had
> to worry about memory and datastructure issues.
> 
> Unfortunately guile documentation didn't anticipate this use at all -
> reading it, you may conclude that guile gives you a cool scripting
> language, and cool language to build high-level layers of your
> application, but NOT a general-purpose reusable C library.

But even in Scwm there are tons of uses of the scm_ interface (and I've
done everything I can to use gh_ whereever possible).  I've kept a list
of the extensions needed the gh_ interface to permit Scwm to avoid using 
the scm_ functions altogether. The list is below (and also in the Scwm
package as scwm/doc/dev/Guile-gh-needs).  I'm in favor of extending the
gh interface where it makes sense.

Greg


Macros
------

SCM_NIMP
SCM_IMP

SCM_CDRLOC
SCM_CARLOC

SCM_EOF_OBJECT_P

SCM_REDEFER_INTS
SCM_REALLOW_INTS

(gh_car/gh_cdr should probably be functions/macros)


SCM_SET_C[AD]R does not do assertion checking, but gh_set_c[ad]r does
   what about if SCM_NEWCELL was just used?

  foo_type *pfoo;
  SCM_NEWCELL(answer);
  SCM_SET_CAR(answer, scm_tc16_scwm_face);
  SCM_SET_CDR(answer, (SCM)(pfoo));

-> 

  gh_newcell_conspair(answer, scm_tc16_scwm_face, (SCM) pfoo)

Functions
---------

scm_error
scm_misc_error
scm_memory_error
scm_wrong_num_args
scm_wrong_type_arg

scm_display_error
scm_display_backtrace

scm_gc_mark
scm_protect_object
scm_unprotect_object
scm_permanent_object

scm_object_property
scm_set_object_property_x

scm_exitval 	
scm_cur_inp	
scm_cur_outp	
scm_cur_errp	
scm_def_inp	
scm_def_outp	
scm_def_errp	
scm_cur_loadp
scm_set_current_input_port
scm_set_current_output_port
scm_set_current_error_port
scm_strprint_obj

scm_gen_puts
scm_puts
scm_prin1
scm_gen_putc
scm_putc
scm_close_port
scm_open_file
scm_mkstrport
scm_char_ready_p

scm_internal_select
scm_makfromstr
scm_sysintern

scm_throw
scm_handle_by_message_noexit
scm_internal_lazy_catch
scm_internal_stack_catch
scm_make_stack
scm_internal_cwdr
scm_eval_x

scm_fluid_ref
scm_fluid_set_x

scm_hash_ref
scm_hash_set_x
scm_hash_remove_x
scm_hashq_remove_x
scm_hashq_set_x


Lily sources have (according to Han-Wen Neinhuys --12/05/99 gjb)
[in addition to the above]

scm_assoc
scm_assoc_set_x
scm_reverse
sm_mkstrpor
scm_ftell
scm_read
scm_fill_input


Types
-----

scm_catch_body_t
scm_catch_handler_t
scm_print_state