Re: bind/shroud bug
>Putting together a test for the routine_id problem, I discovered that =
I've
>ecountered a problem with bind/shroud, not routine_id.
>
>Here's an example that demonstrates the bug; it uses 3 files:
<snip>
>Now, I *know* I can solve the problem by renaming the routines. But =
that
>sidesteps the real issue here: bound/shrouded code BEHAVES DIFFERENTLY. =
This
>is a Bad Thing, and people are not going to be able to convince me
>otherwise.
<snip>
>So here's the conflict: bind/shroud needs to rename things (so they =
happily
>coexist in a single namespace), while routine_id needs the actual name.
>
>I suggest (in my infinite naivite) that a good solution should be =
fairly
>easy to obtain - just add two new tokens to bind/shroud:
>
> <<start of include>>
> <<end of include>>
Whoa... sounds a lot like the "namespace", "end namespace" suggestion =
Pete made. If two people independently come to the same conclusion, I'd =
say the idea has something going for it...
>These would serve to simulate what include does - tell the interpreter =
that
>a new file is being loaded, or exited.
<snip>
>Adding these tokens would ensure that bound/shrouded files are built
>internally the same as plain interpreted programs. I think that this is =
a
>good solution because it:
>
> - makes code bound/shrouded code run correctly
> - should be easy to implement
> - doesn't add any new features
> - doesn't break any old features
> - is backward compatible
> - is simple
I like it. It seems workable, and makes a lot of sense; your points all =
appear valid.
In fact, this idea might even be extensible to include the "limited =
include" idea suggested a while back, by nesting the new tokens. If I =
recall correctly, the main problem was that include files which are =
included in other files force their global declarations on the original =
file; basically, "global" is often too broad of a declaration. =
Naturally, this sometimes led (and does lead) to naming conflicts. But, =
by nesting, this can be avoided:
sequence original
namespace
sequence not_original -- needed, or we conflict with the 1st =
'original'
namespace
sequence original -- now there's no conflict; we're in too =
deep.
-- we just put aside anything 2 namespaces or =
more up
end namespace
end namespace
Of course, a variety of namespace methodologies could be supported this =
way simply by having several forms of "namespace", such as =
"inclusive_namespace", "local_namespace", etc., or by working with a new =
"inclusive" scope declaration (check the archives around Feb. 25 for the =
prior discussion on this...)
Rod Jackson
|
Not Categorized, Please Help
|
|
