Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
Matt Lewis wrote:
>
> 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.
>
I do not see how, within your framework, an application is protected from a new
non interface global identifier popping in a lib's newer version and clashing
with an existing symbol in the application. Could you explain how it does?
More generally, I'd like to see a precise documentation of the new working of
namespaces you are suggesting. It would be much better than just exhibiting a
dozen of contrivedly simple test files, however relevant and useful they may be.
> > > > If the packaging uses a negative list, ie a list of internal symbols,
> > > > then
> adding</font></i>
> > > > 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).
>
Most people run without warning anyway, if only to avoid the silly short circuit
stuff, or "parameter not used" when they are not required in an actual routine
but the prototype cannot change. They are practically useless, even though they
convey useful information.
> > >
> > > 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.
>
As long as there is no clash, there is no need.
Even though it would be nicer for the user to have a wrapper supplied by the
library maintainer, there is no obligation to do so. Either the application coder
or any fourth party can supply one.
> > > 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.
Except when they are not. Besides, my solution also makes it possible to
extend/redefine routines, which is currently tricky and limited, and about which
I don't see how your solution helps.
>
> > > > Huh? It does work for some obvious cases, but explicitly inluding a
> > > > parent
> file,</font></i>
> > > > 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.
Sometimes you just cannot, because the file is meant to be included by several
possible parent files. So at least you should provide a special syntax for
"include parent file". Or have a reserved namespace to designate symbols known to
come from some ancestor (in inclusion tree). Writing relations with parent in
concrete runs counter to any code reuse strategy.
>
> 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.
>
I don't think there is any guarantee, because there are just so many ways
clashes can happen. Again, where are the complete docs? That's the only way one
can tell.
> > > 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?
The advent of name clashes depends on a specific combination of libraries and
application code. So, I don't believe a simple change of rules will prevent all
cases. And user still cannot fignt back without editing third party code.
>
> 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).
>
Adding the include statements may well have other side effects under your
scheme. So, assuming it would only take this amount of work (which I certainly
don't believe), a few library maintainers will need to run another cycle of tests
and release newer versions. Now you are a user and have been waiting for three
years for the next release, how about that? My solution allows for things to
start working (again) now, and the library updates, while welcome, will come when
they may.
And I still uphold that your solution, while it certainly improves on current
Eu, addresses only part of the related issues, and will make the remainder more
difficult to solve in the future. This is exactly what P. Robinson and I were
calling "Band-Aid".
> > 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.
I can't help there, I'm afraid.
>
> > > 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.
>
It uses no new syntax, but is not simpler to handle and certainly leaves more
issues standing.
> > 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.
This isn't even different of how it works now. The more I read, the less
problems I see your scheme solving.
>
> 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
These statements are not backed by any evidence, and I simply don't think they
are true. Actual, detailed documentation is required to assess the scheme; I
tried to come up with one for mine: let me know what is missing. Of course I
agree with poor code always causing trouble, but at least let give users tools to
manage it, as the poor code sometimes is the only available one.
CChris
|
Not Categorized, Please Help
|
|
