On Sun 06 Mar 2011 23:22, l...@gnu.org (Ludovic Courtès) writes: > Hi! > > Andy Wingo <wi...@pobox.com> writes: > >> SCM scm_public_lookup (SCM module_name, SCM sym); >> SCM scm_private_lookup (SCM module_name, SCM sym); >> >> Look up a variable bound to SYM in the module named MODULE_NAME. If >> the module does not exist or the symbol is unbound, signal an >> error. The "public" variant looks in the public interface of the >> module, while scm_private_lookup looks into the module itself. > > So this would be equivalent to: > > scm_module_variable (scm_resolve_module (module_name), sym)
Using scm_module_variable is fine for accessing variables from your own module, but it is not apparent to the user that this actually accesses private bindings and not exported bindings. So strictly speaking, for public variables, you need to do scm_module_public_interface () on the module. But we penalize that with typing. Even given that, though, scm_public_lookup is not the same, because the error cases are different. You want to get the messages, "(foo bar) is not a module", and "baz is unbound in module foo". But you can't get that easily with the existing interfaces. scm_c_resolve_module will always return a module, creating one if none exists. Then scm_module_public_interface returns #f, and then the module_variable would give you an answer like "#f is not a module", which is nonsensical. Furthermore, scm_module_variable returns #f when there is no binding -- a useful behavior in many cases, but as often not useful -- better to get an error that the symbol is unbound, like scm_lookup does. Finally, when you add to this the need to get SCM values for the module and symbol, it's just too much sometimes, and you end up just coding the thing in C. Better to make it easy to use Scheme :) > I’m skeptical about adding 8 convenience C functions “as we move more > and more to writing code in Scheme and not in C” ;-), but if that’s what > people really want, then I won’t object. Understood! I would like to avoid adding new C API, but this one seems to allow us to write less C in the future. For example, with the eval-string-from-file-line case, one can imagine other parameters -- the current language, whether to compile or not, etc. Already there is eval-string which takes a module argument -- do we add an eval-string-from-file-line variant with and without a module? This sort of thing is well-supported in Scheme with keyword arguments, and a pain to do from C. So we need to make it easy for us to say, "just call eval-string from (ice-9 eval-string), and add on keyword arguments as appropriate", instead of encoding all of the permutations into our C API. MHO, anyway! :) Cheers, Andy -- http://wingolog.org/