This is the mail archive of the guile@sources.redhat.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: Will guile ever have (or care about having) users?


>>>>> "TT" == Telford Tendys <telford@eng.uts.edu.au> writes:

    TT> On Wed, Jul 19, 2000 at 12:49:15PM -0400, John Daschbach
    TT> wrote:

    TT> A bit harsh but not too far off the mark.

    TT> I have been using scm_symbol_value0() to fetch the value of
    TT> symbols from within my extension programs. It isn't
    TT> documented, it probably never will be, but it does what I was
    TT> expecting gh_lookup() to do.

Thanks!  I've tried it and it works for what I want.  What I was
looking for was something I would call as
gh_module_lookup(CURRENT_MODULE,sym) but I couldn't easily figure out
how to get the module obarray before I'd entered the repl, which I
think I explained.  scm_symbol_value0() appears to get around this,
but in a couple minutes of reading symbol.c I was unable to exactly
follow how it does this although I think it does this by storing a
closure to handle the lookup for each module in the top level obarray
and then calling that with the symbol again (scm_sysintern0()).

    TT> On the other hand gh_define() does exactly what I would expect
    TT> it to do. This issue has come up on the list before, I
    TT> remember answering it before and it is all about module
    TT> namespaces, something which has been up in the air for way too
    TT> long.

Yes, I don't think I have a problem with this.  What I would *like* is
somethink at the gh_ level like the package system in Common Lisp.  So
I could call, e.g., gh_in_package("guile-user") in my code before I
enter the repl so that in fact all my functions would be registered in
(guile-user).

I find the package system in Common Lisp quite usable, although I have
also found systems which have hierarchical namespaces, i.e. if a
symbol is not found at the current level it is looked for in the one
above, useful.  Perhaps these are only good in interactive use, like
some big math programs.

    TT> Yup, my program boots guile (through stolen main() as per
    TT> requirement) then adds all the extension functions and SMOBs
    TT> into the system, then jumps into the normal REPL to provide a
    TT> prompt to the user.  Thus it behaves like an extended guile
    TT> (i.e. the normal guile prompt is the front end and my code is
    TT> the back end) rather than as an application which uses guile
    TT> as an extension language. In my opinion (and this is based on
    TT> trying these things) guile is easiest to use in the way I am
    TT> using it.

Yes, and this is even basically the advice given in the examples in
the info documents distributed with the CVS code.  Having hacked at
the scm repl in the past I find being able to use the guile repl with
my code, as you do, is a very attractive way to easily make code
interactive.

    TT> Sadly, the ideal approach is yet to be found, and the
    TT> intermediate steps in getting there can be worse than what we
    TT> started off with.

With a little work it would be pretty usable now.  scm_symbol_value0()
goes a long way to helping.  What I think we need, (besides better
documentation!) is a way to enter (guile-user) in the C code before
entering the repl.  

-John




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