Re: [Chicken-users] Modules and environments

[Peter Bex]

On Sun, Aug 30, 2009 at 08:53:25PM +0200, Thomas Chust wrote:
> that's beside the point

It is very much the point.

> Macros just like modules are syntactic
> features of the language. Therefore I think it is quite logical that
> macro identifiers and identifiers possibly mangled by the module
> system behave similarly in some respects.

I think I understand your point now.  You are looking at this from the
module perspective. Modules are indeed not first-class, so it would make
sense if modules themselves are not visible either.

But from a semantic point of view it doesn't make a lot of sense that
a binding introduced by importing a module behaves differently from a
binding introduced by SET! or DEFINE.

> Futhermore, environments are an implementation detail of the runtime
> system. It is, as I said, maybe not very intuitive if the internal
> implementation does not use the same names for variables as your
> source code, but it's not a bug.

I can import the same module twice, using two different prefixes for
example. This introduces two different sets of identifiers, mapping to
the same values.  In common parlance, this gives us twice the number of
bindings available to the code.  If environments cannot see these, it is
not inspecting the *bindings* available in the environment but something
else.

> Following your logic one could also
> claim that it is a bug that after dlopening a chicken-compiled shared
> library from C you cannot access the Scheme bindings under their
> Scheme names using dlsym.

This is an absurd statement and I fail to see how that follows from my
logic.  If there was a shared object inspection facility in Chicken,
it would make sense to have a procedure that could unmangle Chicken
names to C names, or perhaps look up Chicken names and do the unmangling
internally.  This is not unlike what the environments egg could do.
I don't know if modules provide enough introspection information to know
that a given module was imported and how it was asked to mangle its
introduced names, but if this information was stored somewhere I don't
see how environments could not show this information by applying the
reverse mapping the module system does.

It does not need to show the exact internal names because a user is
rarely interested in these (as opposed to a dlsym interface where we
would sometimes want to know the C names).  In fact, I don't think
it's specified anywhere how the module system creates its names and
the current implementation of separating the module name from the
identifier name with a # sign could change at any time.  It's not part
of the interface Chicken exports, so why should a user of the
environments egg have to know these things?

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

pgp1kZIQAUIe_.pgp
Description: PGP signature