Re: gh interface needs for Scwm

[Maciej Stachowiak <mstachow@mit.edu>]

gjb@cs.washington.edu writes:
> A while back I posted the below list of places where we in Scwm violate
> the gh interface of guile and instead use SCM_ or scm_ macros and
> functions.  Since we'd like to be writing to only a published, supported 
> interface, and the guile folks presumably want to make that interface as 
> complete and functional as possible, it'd be great if the gh interface
> could be extended to reduce our dependence on scm internals to only the
> places where the need is real.
> 

I meant to write you about this list earlier, but I may as well do it here.

I am not sure all these things should be added to the gh_
interface. Originally, the gh_ interface was meant to, among other
things, be portable to other Scheme implementations. This means that
many issues simply cannot be addressed (under this philosophy)

If there's been a change of heart on the philosophy of gh_, I'd
certainly be glad to see the listed changes. However, many of them
seem to fall in the categories of: 

* Low-level details of object representation.
* Garbage collection.

* Non-portable Guile features like object properties, error handling,
fluids, hash tables etc.

* Low-level details of printing and I/O.

All of which I think fall outside the current stated range of gh_.

> I'm including the list again below (it may possibly be slightly updated
> from the last time I posted this).  (If there is an equivalent
> gh-exposed construct for any of the below, that'd be great to learn, too).
> 

I'll comment only on the exceptions to my above remarks, the bits I
think should be added to the gh_ interface based on it's current
philophy.

> SCM_EOF_OBJECT_P

A gh_eof_object_p function would be fine for this I think.

> 
> Functions
> ---------
> 
> scm_error
> scm_misc_error
> scm_memory_error
> scm_wrong_num_args
> scm_wrong_type_arg
> 

Errors aren't necessarily all that portable, but at least something
like scm_error should work on any reasonable Scheme.

> scm_set_current_input_port
> scm_set_current_output_port
> scm_set_current_error_port
> scm_strprint_obj

These all would be highly useful although not necessarily technically
portable to any R4+RS Scheme.

> 
> scm_make_vector


There's already a gh_make_vector. I guess scwm is just lamely not
using it.

 - Maciej