Re: Creating modules from C

[Dirk Herrmann]

On 14 May 2001, Marius Vollmer wrote:

> I have totally underestimated the cruftiness of the module system
> interface from C when I gave my suggestions, sorry.

Hmmm.  I am not sure that I fully understand your plans with respect to
cleaning up the module system.  Do your plans include to use the
environments as defined by Jim Blandy's proposal, or is it going in a
different direction?

In any case, there are some points about your suggested interface:

>   - SCM scm_c_export (const char *NAME, ...);
>
>     Add the bindings designated by NAME... to the public interface of
>     the current module.  The list of names is terminated by `NULL'.

Should a module be able to export a binding under a different name? I. e.
should the same vcell (or whatever equivalent) be available under
different names?  This would lead to aliasing problems, since different
identifiers then would represent the same location.  However, if we allow
_imports_ to be renamed, the aliasing problem is already present anyway.

The current implementation of export-environments, BTW, does not provide a
means for renaming exported bindings, thus following Jim's original
proposal.  But, this could be provided easily.

>   - SCM scm_c_module_lookup (SCM module, const char *NAME);
> 
>     Lookup the variable designated by NAME in MODULE.  Throw an error
>     when it isn't found.

If we are going to follow Jim's proposal and naming scheme, this would
rather be named scm_c_module_ref.  It would throw a module:unbound error.

In addition, scm_c_module_bound_p and scm_c_module_set_x functions would
be available:

int scm_c_module_bound_p (SCM module, const char *NAME);
void scm_c_module_set_x (SCM module, const char *NAME, SCM value);

>   - SCM scm_c_module_define (SCM module, const char *NAME, SCM value);
> 
>     Insert a new binding into MODULE, named NAME, and initialize it
>     with VALUE.  Return the corresponding variable.

What happens if a similar binding is already present?  Does this mean that
this function call will instead perform a set! operation?

Is the long term goal to switch from 'variables' to 'locations',
i. e. pairs where the cdr holds the value of the binding, and where the
content of the car is undefined?


...

IMO, it makes sense to first take a look at Jim's environment
proposal.  Maybe we don't want to make use of it.  In any case, for the
design of the module system's C level interface it can be a valuable
resource.

Best regards,
Dirk Herrmann