[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] [Chicken-hackers] Redefinition of imported binding g
Re: [Chicken-users] [Chicken-hackers] Redefinition of imported binding gets implicitly exported
Mon, 04 Nov 2013 22:06:05 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12
> 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
> 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.
> Chicken-hackers mailing list
|[Prev in Thread]
||[Next in Thread]|
- Re: [Chicken-users] [Chicken-hackers] Redefinition of imported binding gets implicitly exported,
Andy Bennett <=