1. RE: another look at namespaces
> From: Pete Lomax [mailto:petelomax at blueyonder.co.uk]
> No-one has given any compelling argument against automatic resolution.
> I suppose I should revisit Mike Nelson's code (23rd May) & see what it
> makes of the more recent cases being discussed here.
Aha! I think I've figured this out (in the Eu source code). I have
automatic resolution working using the Eu 2.4 source. I should have
something releasable by this weekend. (I'm currently porting my 2.3
modifications over to 2.4.)
The modifications solve the alice/bob/chris/diane problem. It was actually
pretty simple. Here's what it does. If you try to reference a global
symbol without namespaces, and the symbol exists in more than one file, it
will attempt to resolve the identity of the symbol based on the 'include
paths' of the symbols. If there is one [and only one] global symbol in the
include path, then that symbol is used. An include path is defined as files
either included directly by a file, or indirectly included by files included
by the file.
Assume:
-- alice.e
global sequence name
name = "Alice"
-- bob.e
include alice.e
global integer x
x = 1
global procedure bob_name()
printf(1,"Bob says name = \"%s\"\n",{name})
end procedure
-- chris.e
global sequence name
? x -- ok, this is dumb, but shows that normal
-- Eu resolution is still in effect
name = "Chris"
-- diane.e
include chris.e
global procedure diane_name()
printf(1,"Diane says name = \"%s\"\n",{name})
end procedure
-- erin.ex
include bob.e
include diane.e
include alice.e as a
include chris.e as c
bob_name()
diane_name()
printf(1,"a:name = \"%s\" c:name = \"%s\"\n",{a:name,c:name})
Running erin.ex gives:
Bob says name = "Alice"
Diane says name = "Chris"
a:name = "Alice" c:name = "Chris"
Matt Lewis
2. RE: another look at namespaces
> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> From: "Matt Lewis" <matthewwalkerlewis at yahoo.com>
> > Aha! I think I've figured this out (in the Eu source code). I have
> > automatic resolution working using the Eu 2.4 source. I should have
> > something releasable by this weekend. (I'm currently porting my 2.3
> > modifications over to 2.4.)
> >
> > The modifications solve the alice/bob/chris/diane problem.
> > It was actually pretty simple. Here's what it does.
>
> The 'it' here is your modification, right, and not current
> Euphoria behavior?
Yes, I meant that once I started thinking about how to implement the desired
behavior, it was pretty straightforward.
> >If you try to reference a global
> > symbol without namespaces, and the symbol exists in more
> than one file, it
> > will attempt to resolve the identity of the symbol based on
> the 'include
> > paths' of the symbols. If there is one [and only one]
> global symbol in the
> > include path, then that symbol is used. An include path is
> defined as files
> > either included directly by a file, or indirectly included
> by files included
> > by the file.
>
> Please find a new term other than 'include path' because it
> took me a few readings of this to realize that your were NOT
> talking about EUINC environment symbol or similar.
Yes, I've been uncomfortable with that, too, just haven't come up with
anything yet.
> It seems that you are describing a heirarchical 'tree' of
> file references; have I got that right?
>
> So the net effect is that ambiguotity is resolved by not
> looking into files that the file that needs resolution has no
> knowledge of.
Correct. The net effect is that whenever you include any third party code,
it should not cause any namespace collision that would require you to edit
any of the third party code.
> Does this also cater for the situation where a file is
> attempting to reference a global that is declared in its
> enclosing file.
>
> -- erin.e --
> global atom xyz
> include bob.e
> include diane.e
> . . .
>
> -- alice.e --
> global sequence xyz
> . . .
>
> -- diane.e --
> . . .
> if xyz then ...
>
> In this case, will diane resolve to the 'xyz' in erin or in alice?
In this case, it will not resolve--you'll get a namespace identifier
required error. Since diane.e doesn't include erin.e or alice.e, it can't
tell which symbol you want.
> --------------
> Here is a another scenario. Hows does this work?
>
> > Assume:
> >
> -- alice.e
> global sequence name
> name = "Alice"
>
> -- bob.e
> include alice.e
> global integer x
> x = 1
> global procedure bob_name()
> printf(1,"Bob says name = \"%s\"\n",{name})
> end procedure
>
> -- chris.e
> global sequence name
> ? x -- ok, this is dumb, but shows that normal
> -- Eu resolution is still in effect
> name = "Chris"
>
> -- diane.e
> include chris.e
> global procedure diane_name()
> printf(1,"Diane says name = \"%s\"\n",{name})
> end procedure
>
> -- erin.ex
> global sequence name name = "erin"
> include bob.e
> include diane.e
> include alice.e as a
> include chris.e as c
> bob_name()
> diane_name()
> printf(1,"Erin says name = \"%s\"\n",{name})
> printf(1,"a:name = \"%s\" c:name = \"%s\"\n",{a:name,c:name})
The output is this:
1
Bob says name = "Alice"
Diane says name = "Chris"
Erin says name = "erin"
a:name = "Alice" c:name = "Chris"
A symbol in the current file still takes precedent over one in another file.
Matt Lewis
3. RE: another look at namespaces
Well done! Will this eventually go to OE?
CChris
> Date: Thu, 10 Jul 2003 14:59:24 -0400
> From: Matt Lewis <matthewwalkerlewis at yahoo.com>
> Subject: RE: another look at namespaces
>
>
>> From: Pete Lomax [mailto:petelomax at blueyonder.co.uk]
>
>
>> No-one has given any compelling argument against automatic resolution.
>> I suppose I should revisit Mike Nelson's code (23rd May) & see what it
>> makes of the more recent cases being discussed here.
>
>
> Aha! I think I've figured this out (in the Eu source code). I have
> automatic resolution working using the Eu 2.4 source. I should have
> something releasable by this weekend. (I'm currently porting my 2.3
> modifications over to 2.4.)
>
> The modifications solve the alice/bob/chris/diane problem. It was actually
> pretty simple. Here's what it does. If you try to reference a global
> symbol without namespaces, and the symbol exists in more than one file, it
> will attempt to resolve the identity of the symbol based on the 'include
> paths' of the symbols. If there is one [and only one] global symbol in the
> include path, then that symbol is used. An include path is defined as files
> either included directly by a file, or indirectly included by files included
> by the file.
>
> Assume:
>
> -- alice.e
> global sequence name
> name = "Alice"
>
> -- bob.e
> include alice.e
> global integer x
> x = 1
> global procedure bob_name()
> printf(1,"Bob says name = \"%s\"\n",{name})
> end procedure
>
> -- chris.e
> global sequence name
> ? x -- ok, this is dumb, but shows that normal
> -- Eu resolution is still in effect
> name = "Chris"
>
> -- diane.e
> include chris.e
> global procedure diane_name()
> printf(1,"Diane says name = \"%s\"\n",{name})
> end procedure
>
> -- erin.ex
> include bob.e
> include diane.e
> include alice.e as a
> include chris.e as c
> bob_name()
> diane_name()
> printf(1,"a:name = \"%s\" c:name = \"%s\"\n",{a:name,c:name})
>
>
> Running erin.ex gives:
> Bob says name = "Alice"
> Diane says name = "Chris"
> a:name = "Alice" c:name = "Chris"
>
>
> Matt Lewis
4. RE: another look at namespaces
> From: Christian.CUVIER at agriculture.gouv.fr
> Well done! Will this eventually go to OE?
>
> CChris
Well, that's one of my motivations for doing this. It gives everyone
something to look at that actually works. Of course, I think it would be
really great if the changes made it into Euphoria itself. I plan to release
the code that I added (two new files: include.h and include.c) so we can all
look at it and make fun of my C skills.
Matt Lewis
5. RE: another look at namespaces
> From: Pete Lomax [mailto:petelomax at blueyonder.co.uk]
>
> >> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> >
> >> Please find a new term other than 'include path' because it
> >> took me a few readings of this to realize that your were NOT
> >> talking about EUINC environment symbol or similar.
> >
> >Yes, I've been uncomfortable with that, too, just haven't
> come up with
> >anything yet.
> >
> How about "local include statements"?
>
I don't think that's quite right. Local include statements says to me that
you're talking about include statements in one file. But I'm really talking
about the include statements within the file, plus the include statements
within the included files, etc. Perhaps 'include tree' would be better. So
for alice/bob/chris/diane/erin:
+-alice <empty>
|
+-bob
| +------alice
|
+-chris <empty>
|
+-diane
| +----chris
|
+erin
|----diane
| +---chris
|
+----bob
+-----alice
In fact, the way it's stored is:
erin: {bob, diane}
bob: {alice}
alice: <empty>
diane: chris
chris: <empty>
The content within {} are a linked list, each of which is a structure
containing the respective index in the array and a pointer to the next item
in the list (if any). So it's pretty easy to determine if one file is in
another's include tree.
Matt Lewis
6. RE: another look at namespaces
> From: Igor Kachan [mailto:kinz at peterlink.ru]
> There are 895 messages on the "namespace" key word in
> the list's archive now.
> The very good addition to the RDS's official Eu documentation
> for better understanding, no?
> The first message on this subject was in 2000 y.
> But I think, I'll better use v2.2 for the first running of my
> new code to get the pure picture about the 3-rd party globals,
> so to say, an old good plane picture without resolutions,
> scenarios etc.
> And I'm SURE, my new code will work on v2.4 without any names
> conflicts if it runs OK on 2.2 after I corrected new names in
> my new code.
Yes, but it seems that you understand the issue with 3rd party globals.
It's easy enough to work around 3rd party globals in your own code, but what
about getting 3rd party globals to play nicely with 4th or 5th party
globals? The current answer is, you can't, unless you edit some 3rd, 4th,
5th, etc party code yourself (adding namespaces or changing names).
Matt Lewis
7. RE: another look at namespaces
> From: Derek Parnell [mailto:ddparnell at bigpond.com]
> Matt,
> of course I support your implementation of this idea, as this
> is exactly the idea I suggested on the 4/Jul in the openEu
> forum [just so I get some credit 
]
Sorry, not trying to take credit for any ideas. I was away over the weekend
(4-7 July for the American holiday plus a friend's wedding) and, of course,
overwhelmed by the volume of messages from euforum and openeu. The message
that caught my attention was Pete's, referencing a May post by Mike Nelson.
> And I like the term 'include tree'. It is exactly what I was
> going to suggest too.
Excellent.
> To Robert:
> I promised that I wouldn't advocate any namespace
> propositions until after 2.4 was released, so I guess I can
> start lobbying now, eh? Please look at Matt's work and
> critique the hell out of it. I can only be the better for an
> authoritative inspection.
Yes, please. And as I mentioned, I'll be very happy to send the source to
anyone who's interested (and already owns the source).
Matt Lewis
8. RE: another look at namespaces
> From: Igor Kachan [mailto:kinz at peterlink.ru]
> > Yes, but it seems that you understand the issue with 3rd party
> > globals. It's easy enough to work around 3rd party globals in
> > your own code, but what about getting 3rd party globals to play
> > nicely with 4th or 5th party globals?
>
> I am not going to *play* with 3,5,7...N-th party globals,
> I am going to use them in my program.
> To use globals I must know them all and well.
Ah, but it's not whether you can use them correctly, but whether the
combination of 3rd and 4th party code conflicts (a la the
alice/bob/chris/diane/erin thread).
> > The current answer is, you can't, unless you edit some 3rd, 4th,
> > 5th, etc party code yourself (adding namespaces or changing names).
>
> What a problem? I'll just replace names in any editor and will be
> SURE my program will work on 10th ... party code.
> MS editor edit.com replaces words in microseconds.
Yes, that will work, but it has to be done for every version, and also
causes library hell (similar to dll hell) if you ever want to distribute
your code. Even though your code uses win32lib v.xx.yy, it has to be your
modified version, not the official version. And there's no way for Derek to
prevent coollib.e from being incompatible with win32lib due to namespace
conflicts.
The auto-resolution really seems to be a natural, elegant and necessary part
of Eu's current namespace implementation.
Matt Lewis
9. RE: another look at namespaces
Hello all,
Can someone summarize what this thread is about
in one or two paragraphs?
Thanks,
Al
