Re: [Chicken-hackers] [Chicken-users] Redefinition of imported binding gets implicitly exported
Hi, I looked into this recently since it also seemed like a bug to me, but the behavior seems to be intentional judging from the code. Even if the behaviour is intentional, there is possibly still a bug. This worked find on my own machine but failed on others so the implicit ordering of something somewhere seems to matter. A workaround is to exclude `process` from the import list in `m` (as in `(import (except posix ...))`) -- this prevents the behavior you're seeing, at least. I need is in some places tho', and if it's used anywhere in a program, it takes over the binding everywhere and seems to become implicitly available everywhere. When `##sys#alias-global-hook` is used to resolve an identifier name for an assignment, it's called with the already-looked-up name from the environment and shortcuts when that identifier is already aliased, returning the imported name (in this case, the built-in `process`) rather than a new, module-prefixed identifier that would shadow the binding like you said. It seems to me that when `##sys#alias-global-hook` is used to resolve names for `set!` forms, it should be called with the bare (pre-se-lookup) identifier, and when `assign` is true and you're currently in a module it should always create a module-prefixed identifier and update the environment, instead of returning the existing alias for imported symbols. But, I couldn't get this to work without breaking other things. CC'ing -hackers. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers Regards, @ndy -- andy...@ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Redefinition of imported binding gets implicitly exported
Hi Andy, all. I looked into this recently since it also seemed like a bug to me, but the behavior seems to be intentional judging from the code. A workaround is to exclude `process` from the import list in `m` (as in `(import (except posix ...))`) -- this prevents the behavior you're seeing, at least. When `##sys#alias-global-hook` is used to resolve an identifier name for an assignment, it's called with the already-looked-up name from the environment and shortcuts when that identifier is already aliased, returning the imported name (in this case, the built-in `process`) rather than a new, module-prefixed identifier that would shadow the binding like you said. It seems to me that when `##sys#alias-global-hook` is used to resolve names for `set!` forms, it should be called with the bare (pre-se-lookup) identifier, and when `assign` is true and you're currently in a module it should always create a module-prefixed identifier and update the environment, instead of returning the existing alias for imported symbols. But, I couldn't get this to work without breaking other things. CC'ing -hackers. Evan ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [Chicken-users] Redefinition of imported binding gets implicitly exported
On Sat, Oct 26, 2013 at 06:51:10AM +1300, Evan Hanson wrote: It seems to me that when `##sys#alias-global-hook` is used to resolve names for `set!` forms, it should be called with the bare (pre-se-lookup) identifier, and when `assign` is true and you're currently in a module it should always create a module-prefixed identifier and update the environment, instead of returning the existing alias for imported symbols. But, I couldn't get this to work without breaking other things. I've said it many times, ##sys#alias-global-hook is nasty and needs to die. Anything short of that would just be us shuffling bugs around, IMO. Sorry I'm not more helpful today. Cheers, Peter -- http://www.more-magic.net ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
