[Top][All Lists]
[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
pgp3osEIYltn0.pgp
Description: PGP signature
- [Chicken-users] Modules and environments, Peter Bex, 2009/08/30
- Re: [Chicken-users] Modules and environments, Thomas Chust, 2009/08/30
- Re: [Chicken-users] Modules and environments, Peter Bex, 2009/08/30
- Re: [Chicken-users] Modules and environments, Thomas Chust, 2009/08/30
- Re: [Chicken-users] Modules and environments, Peter Bex, 2009/08/30
- Re: [Chicken-users] Modules and environments, Thomas Chust, 2009/08/30
- Re: [Chicken-users] Modules and environments, Peter Bex, 2009/08/30
- Re: [Chicken-users] Modules and environments, Thomas Chust, 2009/08/30
- Re: [Chicken-users] Modules and environments,
Peter Bex <=
- Re: [Chicken-users] Modules and environments, Kon Lovett, 2009/08/30
- Re: [Chicken-users] Modules and environments, Peter Bex, 2009/08/30
- [Chicken-users] Re: Modules and environments, felix, 2009/08/31