This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gh interface needs for Scwm


Maciej Stachowiak <mstachow@mit.edu> writes:

> 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)

I didn't mean to imply that everything in my list should be added.  Only 
that everything in the list should be considered and decided whether it
would better to expose it at the gh_ level.

> 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.

Depending on across what subset of Scheme implementation the gh_
interface is meant to be portable, some of the GC calls could be
usefully exposed (there is a lot of similarity among GC algorithms).

<snip>

> 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.

Nah, I just missed it -- I'll check in changes to scwm to use
gh_make_vector. (Did gh_make_vector ever take 3 arguments like
scm_make_vector did?)  Note that there were lots of such changes to scwm
-- we should try to be careful to continue to use the gh_ interface when
it has what we need.

Greg