Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
CChris wrote:
>
> Matt Lewis wrote:
> >
> >
> > Yes, but what about those two libraries. One will have been included in
> > the main app after the other. Did the author use namespaces for everything
> > in his library? The first included library has polluted the namespace.
> > How does the second library manage to deconflict the symbols?
> >
>
> There are two ways around it:
> 1) As explained in my paper, write a wrapper include around say the first
> library,
> and filter the clashing symbol out from there:
<snip>
> 2/ If only a couple symbols cause trouble, which is expected to be the most
> frequent case, it is even simpler to do this:
OK, so the answer is that the user has to write some sort of wrapper for
the libraries to make them work together. For contrast, my approach
requires the user to do nothing to get the libraries to work together.
He only needs to use a namespace (as he would right now) if he wants
to use one of the conflicting symbols.
> > > If the packaging uses a negative list, ie a list of internal symbols, then
> > > adding
> > > more exported symbols requires no update at all.
> >
> > In a perfect world, this would be done. And I agree that this isn't, in
> > and of itself, a deal breaker. I am saying that it's creating another
> > way to create bugs. How would the author know that he'd missed something?
> > That his library causes problems with some other piece of code that hasn't
> > even been written yet?
>
> He wouldn't. By properly marking internal symbols as such, he'd eliminate
> their
> clashing with anything, so only interface symbols may still cause problems.
> If someone uses another library with same interface, then see above.
Yes, if he properly marked them. My ulterior motive with this was to
draw attention to the new warnings I've proposed. The warnings alert a
coder to the fact that the origin of some symbols might be ambiguous
(possibly in the future, when third party code is in the mix).
> >
> > The end result is that the users of the library are going to have to do
> > extra work (by effectively editing the code of the library) to use this
> > library, which is exactly what I'm trying to avoid.
> >
>
> Definitely not true.
> As the examples above show, the system is designed to _completely eliminate_
> any third party code editing. It also enables one to deal with legacy code (ie
> without internal or exported), using export lists in wrapper includes.
I was considering writing the additional wrappers to be equivalent to
editing third party code. I guess I just don't understand why anyone would
want to have to create these wrappers if there were no need.
> > A negative list may reduce the chances of having to go in and edit, but
> > it does not solve the problem. It does, however drive up the complexity
> > of the code.
> >
>
> Not really. SymTab has two more fields, one of them being the initial package
> and the other the current package. If a symbol is *exported*, initial package
> is -1; if *internal*, it is current_package; if *global*, the relevant package
> list is looked up so as to determine whether this is internal or exported.
> Finally,
> keyfind() checks from the current package field if som global is visible.
>
> For example, contrary to your implementation, no change of file structure in
> the front end is required in order to include it as a library. Just a wrapper
> as a stopgap, or marking all current global symbols as internal if they are
> not to be seen outside
I wasn't concerned as much with interpreter code. As I see it, my
proposal just does the obvious thing when resolving symbols, and warns when
there is no such obvious thing, or errors when there are conflicting
obvious things. There's not really any increased mental load for the
coder. Having to manage import lists is just a way to make explicit
things that are actually pretty obvious, IMHO.
> > > Huh? It does work for some obvious cases, but explicitly inluding a parent
> > > file,
> > > for example, is far from anything I'd call "intuitive or straightforward".
> >
> > This really baffles me. You have a file which uses symbols in another file.
> > If that other file is not present, then it won't work. You're saying that
> > it's unintuitive to include that file with the symbols you depend upon?
> >
>
> Since the identifier defined in the parent is already in the known symbol
> space,
> it is counter intuitive to add it again, yes. The only advantage I see in your
> scheme is the dependency being made explicit. Otherwise, it's more typing for
> less functionality, because then all symbols from parent will become viible
> from the included file, won't they? If they don't, read "same functionality".
Here's why I don't think it's counter-intuitive. When looking at the file,
how can you tell where the symbol is meant to come from? The file *does*
have a dependency on its parent file. No more symbols are made visible
than already exist for the child file.
I'd note that it's not a required thing. The difference is that it prevents
an entire class of bugs from occurring. If the include statement is really
that odious, you could put "without warning" in the file. Unlike your
approach, if you follow this rule, and don't let the warnings slide, then
you're *guaranteed* to avoid namespace conflicts with other third party
code.
> > Well, if you're honestly trying to solve the namespace/third party conflict
> > problem then I'd agree with you, and I'd go farther to say that your
> > approach is deeply flawed.
> >
>
> I am trying to solve several related issues around name clashing and scope in
> one sweep, rather than applying yet another Band-Aid. So This is why my
> solution
> brings both encapsulation, overloading and name clash prevention in one
> consistent
> "package".
My problem is that it doesn't really prevent name clashes. True, it gives
the user tools with which to fight back, but why require extra work
where it's not needed?
I also disagree that my approach is a Band-Aid. It is, rather, a fairly
comprehensive solution to getting code from multiple libraries to play
nicely. No currently working code would break, but would allow code
out there that currently conflicts to work immediately (some libraries
might require some minor changes--i.e., adding a few include statements).
> The changes of syntax are:
> * 2 new scope modifiers, *internal* and *exported*, which are mutually
> exclusive
> with *global* and make the intent of the symbol known from just reading the
> code;
> * 2 new with/without directive parameter:
> + *with package <pkg>*/*without package* pushes a package layer onto the
> package
> stack;
> + *with previous_package* pops this stack.
> * 2 new top level directives:
> + *package <pkg> [[!]=<symbol list>]* defines which globals are
> exported/internal
> + *restrict <sym> from <id_def> to <new_scope>* changes the scope of an
> identifier.
>
> As explained, people who write multifile libs or apps that use several
> (multifile)
> libs will need or use some of the new syntax. Hardly anyone else is impacted.
Well, as someone who both writes and uses multiple multifile libs and
apps, I can tell you that I'm not real keen on using the techniques
described to get them all to work together.
> > You still haven't answered the main issue here. How does this solve two
> > third party library conflicts? I'll admit that I simply may not understand
> > your solution well enough, and maybe your examples will clear this up,
> > but you seem to be avoiding the question by saying, effectively, that
> > your solution reduces the number of global symbols, so probabilistically,
> > the chance of a conflict is reduced.
> >
>
> Of course it does. As the code above shows, it also addressesthe clashes
> between
> interface symbols.
I now understand you. As mentioned above, it just gives a coder a
framework to solve the problems. I just prefer a simpler approach.
> Well, it looks like my paper is completely not understandable; however, I
> don't
> know what to do about it, because I had tried to make it as precise and
> detailed
> as I could figure out. Need some hints there.
I was thinking about the problem differently, as something that could be
95% solved by the interpreter, rather than 50%. OK, numbers are made up,
but my real point is that under my system, you can write code that will
100% play nicely with other code. If anything conflicts, the user just
has to use a namespace to differentiate between your library and someone
else's.
There are no new keywords. No new syntax. And coders get an extra warning
that is extremely valuable in pointing out a potential problem. Essentially,
as long as your library is error free, you can be confident that anyone
can simply include it into their code, and it won't cause any namespace
conflicts (of course, other, poorly written code might).
Matt
|
Not Categorized, Please Help
|
|
