chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] Modules and environments


From: Thomas Chust
Subject: Re: [Chicken-users] Modules and environments
Date: Sun, 30 Aug 2009 22:56:53 +0200

2009/8/30 Peter Bex <address@hidden>:
> On Sun, Aug 30, 2009 at 08:53:25PM +0200, Thomas Chust wrote:
> [...]
> 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.
> [...]

Hello,

yes, I agree that this asymmetry looks clumsy, but I don't think a
low-level introspection tool like the environments egg can do much
better unless the internal representation of things is changed in
CHICKEN's runtime system and naming information from macro expansion
time is somehow preserved until runtime. Whether that would be a good
idea or not is a rather different question in my eyes.

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

Nobody ever claimed that the term "binding" as used by the
environments egg was the same as the term "binding" as used by R5RS;
it certainly doesn't have to be, since the way you can access an
environment other than by eval is unspecified by the standard ;-)

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

What I wanted to point out with my dlopen example is precisely that
such information can be lost in the compilation step and one cannot
expect that it should later be recovered magically. The environments
as used by CHICKEN's runtime system know nothing about the names used
for variables in the source code, only about the mangled names
actually generated by the compiler. But just because a program looks
different seen through a reflection API compared to the source code
doesn't mean the reflection tool is buggy to me.

Ciao,
Thomas


-- 
All these theories, diverse as they are, have two things in common: They
explain the observed facts, and they are completely and utterly wrong.
                               -- Terry Pratchett, "The Light Fantastic"




reply via email to

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