Re: proposal: scm_c_public_ref et al

[Andy Wingo <wingo@pobox.com>]

On Sun 06 Mar 2011 23:22, ludo@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> Andy Wingo <wingo@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/