On Sunday 06 August 2006 16:57, Martin Kealey wrote:
> The naive reaction to this is that if you define ['myHLL';'foo'] then
> whether ['parrot';'foo'] is defined (or later becomes defined) is of no
> concern.
If my code depends on the undefinedness of certain symbols, and those symbols
may or may not appear in some namespace somewhere due to something totally
unrelated to my code, I have a problem.
> 2. if myHLL does not actually define ['myHLL';'foo'] but then checks to
> see if it's usable, and would find ['parrot';'foo'] via the normal
> inheriting framework.
> But how often are these actually likely to be the case
All the time, in Pheme. In a very late-binding language, without performing
any external analysis, can you tell if this is a cons or a function
applications?
(foo bar baz)
It's easy in some cases:
('foo bar baz)
(quote (foo bar baz))
It's harder in other cases; it depends on the other symbols available at the
point of evaluation. (You can cheat a little bit at compile-time, if you
disallow symbol removal; cache the define-lambda pairs and store those names
away. Then you can peek at the first atom in a cons to see if it's a defined
symbol or a built-in and avoid the runtime lookup.)
If the answer to that question depends on which version of Parrot people have
installed and it's not a bug in my implementation, but rather symbols leaking
out of the Parrot namespace, that makes my job much more difficult.
Try debugging that.
I don't care for the argument that "It won't happen very often", when it
doesn't have to happen at all and it can cause big, difficult-to-diagnose
problems.
In fact, I can't think of any language port that would *want* Parrot symbols
exposed so easily. Perhaps a new language would, but to my mind that
language would look an awful lot like PIR....
-- c
