guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Creating modules from C


From: Dirk Herrmann
Subject: Re: Creating modules from C
Date: Tue, 15 May 2001 02:43:03 +0200 (MEST)

On 15 May 2001, Marius Vollmer wrote:

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

No, I don't think so.  I just wanted to bring up potential problems that
we should be aware of when coming to a decision.  Moreover, I brought up
the point of renaming exports because I think it may be a sensible thing
to provide.  For example, a library might export the same binding under
different names.

Thus, what I meant to say (but failed to) was:  We should consider to
provide renaming exports.  There is a drawback:  aliasing (which always
reduces optimization potential for compilers), but, hey:  We want renaming
imports anyway, so what?

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

Ah, it will actually return the variable.  I did not get that.  But,
still:  scm_c_module_variable would be along scm_environment_cell
then.  But, this is just names...

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

No, I think that it makes sense to perform a set! then.  But it was not
clearly stated.

Best regards,
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]