Subject: [clisp-list] RFE: list-external-modules

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Wed Mar 12 05:58:01 2003

Sam Steingold suggested:
>Function EXT:MODULE-INFO
>
>Function (EXT:MODULE-INFO &OPTIONAL name verbose) allows one to inquire
>about what modules are available in the currently running image. When
>called without arguments, it returns the list of module names, starting
>with "clisp". When name is supplied and names a module, 3 values are
>returned - name, subr-count, object-count. When verbose is non-NIL, the
>full list of module lisp functions written in C (Subrs) and the full
>list of internal lisp objects available in C code are additionally
>returned for the total of 5 values.

Nice design. Overkill IMHO.

Furthermore, returning "clisp" suggests that CLISP will also return something for (ext:module-info "clisp" T).

I'm against returning the list of objects. So far, I have always been very happy that they were hidden so that the C level could use safe objects that no user or Lisp program would ever see, destroy or manipulate.

There's a difference between src/constsym.d and src/constobj.d. If there's a need for sharing stuff between C and Lisp, then special variables (names!) are what's needed. Unfortunately, the module structure doesn't have symbols. Just objects (i.e. values).

If the functions were to be returned, I believe it would be more useful to return their names (the symbols) than the function objects. A user can simply get the object from the name, but only builtin PRINT and the undocumented SYS::SUBR-INFO know how to get the name out of an object like #<ADD-ON-SYSTEM-FUNCTION FOREIGN-LIBRARY>.

Returning the list of functions may be nice. However, consider module_init_function_1 and _2: a module can do anything. Therefore, it's just some of the things that a module may define that are found in the module_subr and module_object tables which MODULE-INFO can return.
For instance, DEF-C-VAR doesn't show up in the object_table etc.

Given that, I tend to pursue a minimalistic approach: just return the list of external module names (not even the pseudo "clisp" module which is of little use to users), and let people consult the documentation for all this modules gives you. I believe this is enough for most purposes.

Regards,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Wed Mar 12 07:07:14 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] RFE: list-external-modules"
> * Sent on Wed, 12 Mar 2003 14:56:51 +0100
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> Furthermore, returning "clisp" suggests that CLISP will also return
> something for (ext:module-info "clisp" T).

it does - try it!

> I'm against returning the list of objects. So far, I have always been
> very happy that they were hidden so that the C level could use safe
> objects that no user or Lisp program would ever see, destroy or
> manipulate.

well.... :-)
CLISP offers many ways to shoot yourself in the foot, starting with
your FOREIGN-FREE that does not invalidate the object.

> If the functions were to be returned, I believe it would be more
> useful to return their names (the symbols) than the function
> objects. A user can simply get the object from the name, but only
> builtin PRINT and the undocumented SYS::SUBR-INFO know how to get the
> name out of an object like #<ADD-ON-SYSTEM-FUNCTION FOREIGN-LIBRARY>.

of course the names are returned!

> For instance, DEF-C-VAR doesn't show up in the object_table etc.

I know.  where are these c-var's kept?
what about call-ins and call-outs?

> Given that, I tend to pursue a minimalistic approach: just return the
> list of external module names (not even the pseudo "clisp" module
> which is of little use to users), and let people consult the
> documentation for all this modules gives you. I believe this is enough
> for most purposes.

just call (ext:module-info)!

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Daddy, what does "format disk c: complete" mean?