Re: Creating modules from C

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:

> 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?

No, I want to use the environments, but I don't have a detailed plan
that goes that far.

> 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.

Yes, I want to allow one variable (which is the replacement for
vcells) to be reahcable by multiple names, and I want that to happen
mostly via renaming imports.  Will aliasing be a problem?

(In the vcell-cleanup branch, variables don't have names, but there is
scm_module_reverse_lookup, which determines the name of a variable
with respect to a module.)

> >   - 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.

Hmm, scm_c_module_lookup return a variable, while in the environments
proposal, module-ref returns the value of the variable, right?

> >   - 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?

Yes, it will perform a `set!'.  But we can change that, it could also
create a new variable.

> 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?

No, I want to stay with variables.

> 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.

Yes, I will reread it, but I think I would be satisfied with something
really simple right now.