OpenEuphoria

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

• Posted by CChris <christian.cuvier at agr?cul?ure.gouv.fr> Oct 10, 2007
• 832 views

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > Matt Lewis wrote:
> > > 
> > > No, it doesn't climb back up the tree.  I can see the logic of it, but I'm
> > > not sure I agree with this.  Is it really that common?  I know that I've 
> > > occasionally been guilty of this.  
> > > 
> > 
> > How do you have reliable two way communication between a server and a client
> > then? So it is common as soon as your lib/app is not organised in a
> > pyramidal
> > way. By "reliable" I mean, not disrupted by a third party file included
> > alongside
> > a large library.
> 
> You've lost me here.
> 

Why include a file in a program?
Reason #1: so that the including file can rely on routines, and less often
variables, from the included file;
Reason #2, often forgotten: so that the included file can benefit from services
(data or routines) from the including file. By carefully choosing the placement
of the include statement, the including file can control which global identifiers
the included file can access.

Now, if the including file also includes a third party file, and the latter has
a symbol that clashes with one in the including file, then the _included_ file
will have its access to the clashing symbol in the including file disrupted.

I hope my point about client/server is clearer now.

> > >  From the perspective of file2.e, it's not obvious that the correct
> > >  resolution
> > > should be from file1.e. 
> > 
> > Huh?
> > A parent/ancestor is a more likely target than a cousin, don't you think?
> 
> I think you've missed my point.  I agree that the parent is more likely,
> but it's still ambiguous.  file2.e has a dependency that it doesn't make
> clear.

Is the dependency to appear necessarily in file2?

>  The symbol could be from anywhere.  Now, if it added an include
> to its parent, then it would be much clearer.  A better solution might
> be to move those symbols to a separate file that both file1.e and file2.e 
> could include.  This would make things less ambiguous for both the 
> parser and the coder.

This is ok for variables in the including file, but not for routines, as they
frequently access local symbols. If the routines that both file1 and file2 would
include are the only users of the locals they use in file1, then these locals can
be moved to the new file, but this is a rather rare, favourable circumstance.
Your scheme would increase the use of global symbols because of the unnatural,
inconvenient splitting of files.

> 
> > > I think it might be better to give an error in
> > > this case.  The resolution would be to include the file explicitly.
> > 
> > Which means file2.e should include file1.e, even though file1.e includes
> > file2.e?
> > It makes sense, but will such a sea change - allowing circular includes - be
> > accepted? I would.
> 
> They are currently accepted.  There is no change, except that we still
> need a mechanism for allowing symbols in a direct include to mask those
> of an indirect include.
> 
> Matt

Currently, they are accepted, but ignored, as the target of the second include
statement is already known from parser.  The change is that, however, note would
be taken of the inclusion attempt so that the included file can see symbols from
the including file. And care is needed so that only the known symbols in the
including file at the time it includes the included file are visible from it, not
all global symbols. Or did I get anything wrong?

CChris