#911 closed defect (worksforme)
,m still mixes up namespaces and renamings
Reported by: | Christian Kellermann | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.9.0 |
Component: | core tools | Version: | 4.8.x |
Keywords: | csi, m command module system | Cc: | |
Estimated difficulty: |
Description
Hi,
due to a discussion on IRC I have noticed that the ,m command still does not work as desired. For example, I would expect this to work:
CHICKEN (c)2008-2011 The Chicken Team (c)2000-2007 Felix L. Winkelmann Version 4.7.5 (rev e061038) linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ] compiled 2012-08-31 on devpool08 (Linux) ; loading /home/ckellerm/.csirc ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/parley.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/chicken.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/data-structures.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/extras.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/ports.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/posix.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/srfi-1.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/srfi-13.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/srfi-18.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/stty.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/srfi-69.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/foreign.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/foreigners.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/parley.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/stty.so ... #;1> (use irc) ; loading /home/ckellerm/chickens/master/lib/chicken/6/irc.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/matchable.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/tcp.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/regex.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/irregex.import.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/irc.so ... ; loading /home/ckellerm/chickens/master/lib/chicken/6/regex.so ... #;2> ,m irc ; switching current module to `irc' #;irc:2> default-port ; not exported constant in the irc egg Error: unbound variable: irc#default-port #;irc:2> make-irc:connection ; not exported constructor of the connection record Error: unbound variable: irc#make-irc:connection #;irc:2>
Change History (3)
comment:1 Changed 12 years ago by
Component: | unknown → core tools |
---|---|
Keywords: | csi m command module system added |
Priority: | major → minor |
comment:2 Changed 12 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
This is not a bug: in compiled modules, unexported identifiers do truly not exist: they are hidden and effectively optimized away, stored in some location only known to the compiler. Unexported bindings can be inlined and removed completely in many cases. So switching into the module can not make them magically appear again. This is different when using interpreted code: here even hidden bindings still exist, even if hidden. If you think this is an inconsistency between compiled and interpreted code, you are right. But the compiler must be able to remove non-exported bindings, for performance reasons.