OpenEuphoria

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

• Posted by CChris <christian.cuvier at agricultu?e.gouv.?r> Oct 10, 2007
• 862 views

Matt Lewis wrote:
> 
> CChris wrote:
> > 
> > 
> > Does the include tree also contain the direct ancestors? If not, there are
> > some
> > issues with this scheme, which is quite common:
> > }}}
<eucode>
> -- file1.e
> include third.e
> global integer n_also_in_third
> n_also_in_third=n_init() -- ok, this g.s. shadows anything in third.e
> include file2.e
> --...
> > 
> -- in file2.e
> integer my_var
> my_var=n_also_in_third 
> -- could produec an error, while   
> -- file1.e::n_also_in_third is obviously being targeted
> </eucode>
{{{

> > As the name suggests, n_also_in_third is also a global symbol defined in
> > third.e.
> > I'd consider it a problem if this isn't properly handled.
> 
> 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.

>  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 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.

> 
> Continuing my train of thought from the response to Pete, I guess a legitimate
> question to be asked would be whether we should let symbols in directly
> included files mask those from lower down in the tree?  Assuming, of course,
> that no namespace identifier is used, and there is only one possible symbol.
> 

Definitely yes, that's the only way to extend routines that are not builtins -
something which is hard to do currently, other than using clumsy call_func/proc()
calls.
One could always use namespacing to access the shadowed symbols.

> I'm also starting to think that any symbol resolution from beyond the 
> include tree should generate a warning.
> 

It doesn't hurt, agreed.

> Matt
CChris