OpenEuphoria

Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)

• Posted by CChris <christian.cuvier at agricultur?.gouv.?r> Oct 11, 2007
• 828 views

Matt Lewis wrote:
> 
> Pete Lomax wrote:
> > 
> > Matt Lewis wrote:
> > > 
> > > What if main.e had also included libAmisc.e?
> > > 
> > > }}}
<eucode>
> > >  main.e
> > >    global Z
> > >    include libAmisc.e
> > >      if Z then
> > >    include libA.e
> > >      global Z
> > >      include libAmisc.e
> > >         if Z then
> > > </eucode>
{{{

> > > Now how would the interpreter handle this?
> > >
> > Well, yes, that would break it for sure, ... but ... that code has been
> > broken
> > since the year dot (without any warning) so I struggle to accept that
> > example
> > as relevant.
> 
> Yes, the point is that we're trying to fix things so that we can reasonably
> use third party code without having to modify any of it to make it play
> nicely together.  This particular exercise is basically taking things to
> their logical conclusions, and to try to get it right the first time,
> rather than to have to revisit this later.
> 
> I extended CChris' question to cover a more worrisome example, basically
> in an effort to explain why I disagreed with him.
> 
> > >  It has to be an error
> > <snip>
> > > I bet that I'll find a lot of this in various libraries of mine.
> >
> > I am quite worried that absolute torrents of the warning you propose will
> > occur
> > in legacy code. On a lesser note, it seems to me that while you could give
> > said
> > warning in the libA standalone case, it would be nigh on impossible for the
> > code snippet above to actually produce a compile error?
> 
> Why are you worried?  Adding a warning doesn't create the problem, it just
> alerts us to a problem that already exists, and gives us a chance to
> fix it before it starts causing problems.  While there are some warnings 
> that can be ignored (like short circuits--assuming you understand the 
> implications), this is one that should really be corrected.
> 
> You're right about the compile error.  The problem here is that it
> would use the *wrong* Z, so not a compile error, but a bug that could be
> fixed based on the warning.
> 
> Here's how you might get a compile error:
> }}}
<eucode>
> --main.ex
> global constant Z = "main"
> include libA.e
> 
> --libA.e
> global constant Z = "libA"
> include libAmisc.e
> 
> --libAmisc.e
> printf(1, "libAmisc.e: Z = '%s'\n", {Z})
> </eucode>
{{{

> Now, if you include libAmisc.e in main.ex before libA.e, you'll get 
> the wrong Z.  Or, if libA.e is included before Z is declared in main.ex,
> you'll get the correct Z, but only as long as there's not a Z declared
> earlier (including, of course, in files like libB.e).
> 
> Now, as a thought experiment, replace Z with something like TRUE.
> 
> Matt

I have thought a fair deal about this, and what I have been readingmakes my
earlier point even clearer: tinkering with namespaces cannot solve the problem of
having several multifile libraries play together without modifying any of them.
You need a _different_ concept, which is one of a _set_ of files being
collectively grouped together. Namespaces apply to only one file, with or without
inheritance.

In order for applications to use any combinations of libraries and to be immune
to any change in their inner working, subdirectory layout and whatnot, you'll
have to make explicit the distinction between an interface symbol - which is
meant to be available everywhere, except if explicitly shadowed - and a multifile
symbol, which is meant only to be seen from a specific set of files. For
historical reasons, the two are currently defined as "global": this makes the
proper handling of current code more complex.

I still consider the kind of proposal I had put forward before as more relevant
than a simple change in namespace semantics, which is not solving the problems,
or replaces them with others, as the recent posts show.

See http://oedoc.free.fr/Packages.htm for a complete description. I have a
working copy of eu.ex using this scheme. One could remove the "with
previous_package" directive, at the expense of a little more file splitting, as
symbols of different packaging status should have to go to different files then.

I'll emphasize again that the dual export list mechanism described there is
meant as a _transitional_ feature, whose purpose is to allow immediate wrapping
of existing code so that it works without clashes now, without having to wait for
it being rewritten. This is why the scheme is far less complicated than it might
seem to some.

CChris