This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Names in libguile
- To: "Greg J. Badros" <gjb at cs dot washington dot edu>
- Subject: Re: Names in libguile
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 17 Mar 2000 18:41:49 +0100
- Cc: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>, guile at sourceware dot cygnus dot com
- Cc: djurfeldt at nada dot kth dot se
- References: <E12VeE6-0004Sb-00@mdj.nada.kth.se> <qrrbt4dlfi8.fsf@clavicle.cs.washington.edu>
"Greg J. Badros" <gjb@cs.washington.edu> writes:
> All of these notes should be summarized and stuck in a file in the
> guile-core module (and updated).
>
> One of my pet peeves is that macros ending in P are predicates that
> evaluate to a C boolean, gh_foo_p()s are predicate functions that also
> return C booleans, but scm_foo_p()s are primitives that return SCM
> booleans. There is a funny interaction that I don't like, there. I'm
> not sure that there's any solid way to fix this since there's already a
> lot of code that relies on the gh_ interface. The void* patch will help
> catch these bugs, but the distinction should at least be made very clear
> up-front in developer docs for Guile if we can't figure out a
> backward-compatible reasonable solution.
Yes, very good suggestions.
We should have a special devepment directory, maybe
"guile-core/devel", which is not packed with the distribution.
In this directory we could have subdirectories like
policy
policy/names.text
policy/changes.text
modules
modules/environments.texi
...