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: Peter Bex
Subject: Re: [Chicken-users] Modules and environments
Date: Sun, 30 Aug 2009 23:11:23 +0200
User-agent: Mutt/1.4.2.3i

On Sun, Aug 30, 2009 at 10:56:53PM +0200, Thomas Chust wrote:
> 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.

Environments is not presented as a low-level introspection tool.

> 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 ;-)

Wow, that's a nice feat of language lawyering ;)
If it uses different terminology from R5RS, the environments egg's
documentation should include big fat warnings stating this fact.

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

Yes, I appreciate this point now.  However, it's still unclear whether
this is its intention (is it intended as a "low-level tool" or as a
more high-level one).  If it is, it should certainly be documented
because the "intuitive" notion would be that it's a high-level tool,
reflecting the standard terminology and interface you see in regular
code.  I'd also be disappointed because I always expected it to be the
high-level tool, and I have no use for the low-level tool you described.

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

Attachment: pgp3osEIYltn0.pgp
Description: PGP signature


reply via email to

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