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
pgpv6YdNmxA9l.pgp
Description: PGP signature
_______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
