1. Re: Namespace (Is that your final answer?)
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Namespace (Is that your final answer?)
Hi Irv,
thanks for helping me understand your proposals a bit better. Having a
"discussion" via email is difficult because its hard to really get across
all our meanings in a simple emotionless exchange. Please bear with me some
more.
>
> On Wednesday 27 June 2001 02:24, Derek Parnell wrote:
>
> > > 2. Any references to a variable NOT declared in this file
> > > MUST have been declared in a previously included file
> > > (file.a) - if not, this is an error, which Euphoria
> > > already knows how to handle.
> > > Therefore, replace those references with the already
> > > qualified name from file.a <file.a.pi>
> >
> > Are you saying that if, say, delta is referenced in file.b but not
defined
> > in file.b then the author assumes that it is being defined in another
file?
> > That make sense. But why do you then leap to the conclusion that is must
be
> > in file.a? The symbol called delta could be defined in any included file
or
> > even in the file that is trying to include file.b for that matter. Does
the
> > interpreter have to search all known global symbols to find which file
> > delta might have been defined in? What if was defined in more than one
> > file?
>
> Just exactly the same as it works now - if 'delta' is referenced, and
> there's no declaration of 'delta' somewhere earlier in the file, then
> there MUST have been a (global) declaration in a previously included
> file. If not, then it's an error now, an error in 2.3.
Yes of course this is right. I agreed to that. Notice that I wrote "...That
make sense." above.
> No, I'm not leaping to any conclusion about where the variable
> was previously defined.
Its just that you wrote "MUST have been declared in a previously included
file (file.a)", which looked like you were saying the it HAD to be from
file.a. I guess what you meant was more like "MUST have been declared in a
previously included file (such as file.a) or even the current file"
>Euphoria obviously allready keeps track
> of what variables have been defined. See any error message.
> So tracking the source file for such variables would only mean adding an
> index to that variable indicating the point at which it was defined.
Yes, I know this too.
> Also, Euphoria quite obviously already does a search of all known
> global variables - how else could it warn you about duplicates?
Its getting a little confusing for me. I was thinking that you were talking
about a v2.3 that would allow duplicate global definitions and thus would
NOT be warning you. Of course v2.2 searches the global list so it can warn
you of this situation.
> As far your question re: "what if it was defined in more than one
> file?" - Euphoria already knows that too, and tells you.
> The problem is, once it tells you, it throws in the towel, and
> gives up. That's not really necessary.
I agree its not really necessary for Euphoria to throw in the towel. And I
also can see that v2.3 will need to keep the file name(path?) of where a
global was defined in its global list. No arguments here.
> > > 3. If a variable IS declared in this file, and a variable with
> > > an identical suffix has ALREADY been declared in an
> > > earlier file, Euphoria needs to let you know, so you
> > > can write your code to refer to the desired variable.
> > > Possible message:
> > > Warning - Duplicate identifiers:
> > > file.a atom pi line 2 <file.a.pi>
> > > file.b sequence pi line 1 <file.b.pi>
> >
> > Now this is the next problem that arises once the reDEFINE problem is
> > fixed: If we can define a global symbol in more than one include file,
how
> > do we now refer to individual "redefined" symbols? You don't seem to be
> > offering a solution here. You mention that we need to code to make the
> > ambiguity go away, but how do we do that? Are you suggesting that we
> > manually prefix our reference to pi with the file name? Such as ...
>
> You are quite correct, in a literal sense. I am not offering a solution
> "here", if by "here" you mean the current paragraph.
> If, however, you had read further, you would have discovered that
> I offer exactly the same solution as you do, in a later paragraph.
Sorry. Yes I did mean "the current paragraph". And I did read further on as
well, before replying. Its just that it seemed that the solution you
proposed further on appeared to be worded as an alternate or additional
solution to another solution that was not explictly described. I'm sorry I
misread your message.
>
> > -----------------
> > include file.a
> > include file.b
> >
> > x = sin(file.a.pi + a) * cos(file.a.pi + b)
> > -----------------
>
> Well, you are going to have to manually pre-fix the variable with
> SOMETHING, unless you let Euphoria do it for you. There's no
> other option, other than letting Euphoria select at random.
> I certainly agree that the syntax 'file.a.pi' is awkward, which you
> would have discovered if you had read ahead.
>
> > I hope not, because I still feel that file names make poor namespace
ids.
> > For example, if I have to code pi in many places, and prefix each the
the
> > file name, I suspect that the file name would be something other than
> > "file.a", maybe "transandentals.e" which makes for one long prefix. Then
> > what if I change the file name to something else. I now have to edit my
> > code in many places to reflect the new file name. This might happen if
yet
> > another author supplies a better transandental library!
> > I'd rather do this...
> > -----------------
> > include transandental.e as tl
> > include file.b
> >
> > x = sin(tl:pi + a) * cos(tl:pi + b)
> > -----------------
>
> Which is exactly what I suggested when I wrote:
> include file.b as B
I'm glad we can agree on this concept.
> > then if I change the library ...
> > -----------------
> > include new_improved_transandental_library.e as tl
> > include file.b
> >
> > x = sin(tl:pi + a) * cos(tl:pi + b)
> > -----------------
> >
> > > One problem remains:
> >
> > Only one!?!?! I wish.
> >
> > >imagine the following scenario:
> > > file.a declares atom pi
> > > file.b declares sequence pi
> > > file.c includes file.a and file.b
> > >
> > > Which pi does file.c refer to?
> > > Maybe you didn't write file.c, and CANNOT change it.
> > > So how is Euphoria to know how to properly qualify
> > > the references to 'pi' in file.c?
> >
> > Well I presume this can only happen if a newer version of either file.a
> > and/or file.b was supplied after file.c was created. Otherwise the
author
> > of file.c ought to have resolved this issue already.
>
> What if the author of file.c (let's call it Win32Lib), isn't also the
author
> of file.a and file.b?
Which is exactly the situation I was also thinking of.
>Should he prevent the author(s) of those files from
> making changes / improvements / upgrades for the sake of his program?
No, absolutely not!
> Or should he 'fork' their code and create new, incompatible with
everything
> else versions of file.a and file.b to be reserved (and maintained) just
for
> use in Win32Lib?
No, absolutely not!
>
> Suppose the author(s) of file.a and file.b don't WANT unauthorized
> changes to be made to their code, because downloading an un-authorized
> copy might break their existing programs, and get undeserved complaints?
Exactly my point too.
> > > Short answer; Euphoria CAN'T know - you have to tell it.
> > > If you can't modify either file.a, file.b or file.c, how do you
> > > do this? With advance instructions.
> >
> > Hang on. What makes you think I know which 'pi' file.c needs? If I can't
> > inspect file.c it might be a bit difficult to determine. Even if I come
to
> > the conclusion that file.c was using the 'pi' in file.b because file.a
is
> > the new one, how do I know if this the best choice. I'm not the author
of
> > file.c, file.b or file.a so I'd be making an educated guess, but still a
> > guess.
>
> If you can't inspect file.c, then how are you using it?
> Pure guesswork? More likely, you have a list of the global variables and
> functions declared within and available for your use.
> (a.k.a. documentation), or you have the source to read.
>
> If it comes down to guessing, I am fully confident that your best
> guess would be better than Euphoria's, which is the only alternative
> I can see, other than contacting the authors of the other files to
> ask them.
>
> > It could be that I don't even know which files are being included inside
> > file.c!
>
> Reallly? Let's examine that possibility, with the assumption that you
> have neither the source nor the documentation for file.c:
>
> 1. You don't have the proper include. Here's what Euphoria currently
> reports:
>
> test.exu:1
> can't open grump.e or /home/irv/euphoria/include/grump.e
> include grump.e
>
> Perfectly adequate, no changes needed, or possible. You just
> go get grump.e
>
> 2. You do have the needed include, and it's the only one which declares
> a global "pi".
>
> The program runs. Just like it does now. You don't need to do anything
> further. Again, no changes are needed in Euphoria.
>
> 3. You have the required includes, but two or more use the same global
> identifier. Here's what Euphoria says about that situation now:
>
> file.b:1 <== here's the second file which declares 'pi'
> attempt to redefine pi
> global sequence pi <== here's the type
>
> You'll note that in paragraph 3, I suggested the possibility of expanding
> this message to indicate not just the second instance, but both instances
of
> the declaration:
> Possible message:
> Warning - Duplicate identifiers:
> file.a atom pi line 2 <file.a.pi>
> file.b sequence pi line 1 <file.b.pi>
>
> Is this not enough information to determine which includes are used?
You're correct. I didn't read the expanded messages well enough. They do
give enough information to correct it in the manner you suggest.
> > > Before you include file.c, you've got to tell Euphoria
> > > how to qualify the pi in file.c, when it does read in file.c.
> > > Your syntax may vary, but I suggest:
> > >
> > > include file.c using pi from file.a -- simple, no?
> >
> > No. Not simple at all. If I pick the wrong 'pi' I could be causing other
> > problems.
>
> If you change or use any variable or function without knowing
> what you're doing, it could cause problems. Why are you picking
> the wrong "pi"?
Well, with the information in the expanded messages, there is no excuse for
picking the wrong 'pi'. However, it doesn't mean that one will do the right
thing just because one has all the information needed to do the right thing.
I was think of an *extremely* unlikely scenario where simultaneously there
was not one new 'pi' but many new 'pi definitions. So it would be possible
(but not too clever) for one to code ...
include file.c using pi from file.z
just because file.z has also got a 'pi' definition in it!
However, this is just nitpicking and I shouldn't have even mentioned it.
Sorry.
> If you don't know which "pi" to USE, how on
> earth are we to trust you to CHANGE the SOURCE of the file
> where "pi" is declared - thus breaking not only your own program,
> but everyone else's as well?
I hope you are not alluding to my ability (or lack thereof) in maintaining
Win32Lib.ew. I would be very hurt and offended if you were.
But the discussion, I thought, was (hypothetically) from the point of view
of a person writing a program that included file.c (eg win32lib.ew) which in
turn included file.a (eg machine.e) and file.b (eg dll.e). If so, that
person would NOT be changing anything in file.c (ie win32lib.ew) .
> > However, I agree that this is a real issue that should be addressed.
> >
> > My "solution" is that the author of file.c should be more careful. That
> > author should have already resolved future clashes before they could
> > happen.
>
> > FILE.C is
> > -------------
> > include file.a as a
> > include file.b as b
> >
> > x = y * a:pi
> > --------------
> >
> > Now when a new version of file.b is introduced that has 'pi' in it,
file.c
> > is already protected because it specifically refers to the version of pi
it
> > wants. Call it defensive coding if you like.
>
> Here, I agree with you. That was what prompted my comment that
> library files should be required to use the extended "include ... as"
> syntax. The current alternative is to use names so obscure that
> no one else would ever dream of using them. We're finding that
> that's not a practical alternative.
Thanks. In my case with win32lib.ew , when namespaces come out in v2.3, I'll
be upgrading win32lib.ew et al with fully qualified references to symbols
that are defined in any included files, in an attempt to alleviate problems
for people using win32lib.ew. Unfortunately, it means that I will have to
maintain and publish a v2.2 and a v2.3+ version of the library. I'm thinking
of keeping the master source with embedded #define type of directives and
using a utility to generate the v2.2 and v2.3+ source codes. Not a pleasant
thought.
> > I know that this doesn't resolve the situation you cite, and I don't
really
> > know how to do that safely.
>
> I thought I explained that fairly clearly. I repeat:
You did. I didn't read it clearly though.
> So how is Euphoria to know how to properly qualify
> the references to 'pi' in file.c?
>
> Short answer; Euphoria CAN'T know - you have to tell it.
> If you can't modify either file.a, file.b or file.c, how do you
> do this? With advance instructions.
>
> Before you include file.c, you've got to tell Euphoria
> how to qualify the pi in file.c, when it does read in file.c.
> Your syntax may vary, but I suggest:
>
> include file.c using pi from file.a -- simple, no?
Simple, yes. Provided that there is only ONE such exception to deal with.
Should we have something like ...
include file.c using pi,delta,theta from file.a
and using alpha,epsilon from file.b
and using zeta,omega,gamma from file.f
and ... (you get the picture)
> There's no other place where you can expect to control
> the names of globals, except AT THE TIME EUPHORIA LOADS THEM.
> And that's the appropriate place to do so, since you are the only
> one who is using that exact combination of files. You have,
> by electing to use a set of include files, created a unique situation.
> It's up to you to make that situation work, not by having others
> change their code, nor by you changing their code, but by
> YOU changing YOUR code. Euphoria should make this
> easy. I think the method described above is straightforward
> and simple. Best of all, it can't BREAK anything, AFAIK.
You're correct in that it won't break anything. I guess my only really
hesitancy is around the idea that it puts a burden on the wrong person. I
means that the person using file.c has to resolve the problem, where as I'd
have wanted the author of file.c to have the burden of making there product
bullet proof in the first place. But of course, that just isn't always
possible with legacy library files.
In short, I think that your suggestion should be considered by RDS, in
addition to Euphoria also enabling library authors to reduce the chance of
name clashes happening in future.
In fact, I just had a thought. In another message I suggested an "insert"
feature. If something like this was available, it means that I, as
maintainer of win32lib.ew, could create a file that contained the fully
expanded list of "using" phrases and you as a user of win32lib, could insert
that file. This would make it my responsiblity to keep win32lib correct
rather than its users.
eg. In your program you could code...
include win32lib.ew @"win32lib.us" as w32
where the file called "win32lib.us" would look like ...
using open_dll, ... from dll.e
and using message_box from msgbox.e
and using (... etc...)
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
