1. Re: Namespace (Is that your final answer?)
How about implementing this by means of a
without redefinition
(default) i.e. as of now, and
with redefinition
i.e. when the interpreter hits the redefinition attempt it adds the dot
notation ?
As for the
> include file.c as C using pi from file.a
it looks like an excellent idea, but I'd carry it a bit further, since this
format might lead to interminable error-prone lists, as in
include file.c as C using pi from file.a, e from file.b, up from file.z,
down from file.somefile, strange from file.weird, charmed from
file.haliwell, ...
I'd leave the include asis, and allow for dynamic assignment, in the form
pi = file.a.pi
This wouldn't conflict with using the dot notation at the same time, so you
could have
include mathcons.e -- which contains a definition for pi
include mathvars.e -- containing another pi
atom pi -- your very own pi
? pi -- obviously, yours
pi = mathcons.pi
x = z * pi
.. and so on. Obviously would require careful and close supervision, but it
grants you enormous flexibility.
Gerardo
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Sent: Tuesday, June 26, 2001 11:46 AM
Subject: Re: Namespace (Is that your final answer?)
> I'm pretty sure that Rob would like any namespace
> solution to apply retroactively, so that all the hundreds
> of user-contributions in the archives would all happily
> co-exist. No one wants to re-write all of those. Just
> testing all combinations would be a daunting task,
> one I estimate would take eternity plus two weeks,
> given that you'd have to start over every time a file
> was added or changed.
>
> To arrive at a workable solution, we have to first agree that
> ALL existing code is for practical purposes "off limits"
> to our own modifications. Why? Because:
>
> 1. It might be shrouded
> 2. It may be too complex for us to fix.
> 3. 'Fixing' something might break other packages that
> depend upon the one we're 'fixing'.
> 4. Our fix would have to be made part of the 'official'
> release, or next time the package was updated by
> the original author, our 'fix' would disappear.
> 5. There would be a proliferation of different non-
> interchangeable versions of every package.
>
> IOW, we shouldn't break other peoples' code just to
> make our sorry program work.
>
> So, if ALL existing library code is off limits, just what
> DO we have control over? Our code, obviously.
> What does our code do that could help? It "includes"
> these other packages, either directly, or indirectly.
>
> How can this help? Let's look at what happens now
> when I include file.a and file.b into my program.
> File.a and file.b were written by two different people.
> They didn't test them together, so both files make use
> of commonly used variables (x , y, or pi, for example).
>
> It won't run. How do I know? The interpreter TELLS me so.
> Here's the message:
> file.b:1
> attempt to redefine pi
> global integer x, pi
>
> Even if the include files are shrouded and scrambled,
> Euphoria still tells me the problem:
> file.bs:4
> attempt to redefine pi
> <scrambled code>
> ^
> OK, there's enough info here to tell me what's wrong, but
> I can't do anything about it - remember, ALL library code
> is considered off limits, for the reasons given earlier.
>
> I can't do anything, but Euphoria can - without even
> touching the source code. How? By simply changing
> the INTERNAL representation of the variables, following
> some simple rules:
>
> 1. Where a variable IS declared in this file, (file.b)
> qualify the declaration by prepending the filename,
<snip>
