This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: thanks
- To: Miroslav Silovic <silovic at zesoi dot fer dot hr>
- Subject: Re: thanks
- From: Doug Evans <dje at transmeta dot com>
- Date: Sun, 5 Dec 1999 11:21:52 -0800 (PST)
- Cc: hanwen at cs dot uu dot nl, Jim Blandy <jimb at red-bean dot com>, guile at sourceware dot cygnus dot com, jantien at xs4all dot nl
- References: <14408.17885.875301.897078@dokkum.cs.uu.nl><m3iu2el61g.fsf@savonarola.red-bean.com><14410.35733.598024.200814@dokkum.cs.uu.nl><7eemd1xmei.fsf@zesoi.fer.hr>
Miroslav Silovic 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.
It's wrong for an app to use both gh_* and scm_* (*1).
[Or am I misunderstanding the purpose of gh_*?
As I understand it, gh_* was put in to isolate apps from the
implementation details of SCM. True?]
Assuming that's correct, I wonder if time spent on gh_* is
best spent elsewhere.
--
(*1): But given the current state of gh_* it's understandable.
The point here is not to criticize the apps but rather to
probe what the long term future of gh_* is.