OpenEuphoria

Re: 3.2, namespace and symbol resolution -- Matt?

• Posted by Derek Parnell <ddparnell at ?i?pond.com> Apr 18, 2008
• 506 views

Matt Lewis wrote:

> One of the big problems was if two third party libraries declare global 
> symbols with the same name.

Here's a thought or two ...

Firstly, some principles ...
(A) A file should only be able to 'see' global symbols that have been defined in
another file, if the first file has actually included it (directly or
indirectly).
(B) A developer should never have to modify an included file in order to resolve
a name clash.

With these two principles in mind, most things will work out of the box. But
there are a couple of situations that need special treatment.

There are times though when a file actually needs to see a 'foreign' global
symbol - usually one that has been declared in the file that is inclucing the
file that wants access. (eg. FOO.EX includes BAR.E, and BAR.E wants to see a
global defined in FOO.EX).

Assuming that we can't alter BAR.E but we can alter FOO.EX, I propose a new
statement - 'export'. The 'export' statement would make the exported symbol
global and available to included files. So in our example, we would place lines
like this in FOO.EX ...

  export constant magic_word = "xyzzy" 
  include bar.e

Now BAR.E can see the magic_word. If magic_wod was just a global, BAR.E should
not be able to see it. I know this breaks existing functionality but it might be
worth it.

The other situation, which a lot more common, is when two included files happen
to use the same name for a global symbol.

The first suggestion I have for this is whenever a global constant has the same
name and same value as another global constant, they should be considered to be
the same thing - and not cause a name clash.

So, when FOO.EX include BAR.E and includes NAT.E, and both BAR and NAT define a
global symbol called 'cave' it only causes a problem for FOO.EX if that file
access a 'cave' symbol. FOO.E can't see anything in BAR.E and visa versa. The
current namespace concept works here for FOO.EX.

   include BAR.E as bar
   include NAT.E as nat
   . . .
   saveb = bar:cave 
   saven = nat:cave

The change that I think is need though is to have the namespace apply to all the
globals that an included file can see. If we change our example slightly such
that FOO.E doesn't define 'cave', but instead includes POT.E which defines
'cave'. From the point of view of FOO.EX, the 'cave' that BAT.E can see may as
well been defined in BAT.E or any file that BAT.E gets to include (directly or
indirectly). So, from FOO.EX's point of view, the namespace qualifier applies to
all of BAT's globals. So we still do the code above to access the 'cave' defined
in POT.E even though FOO.EX doesn't know about POT.E. It still uses the 'bar'
namespace to get at it.

One final problem is where NAT.E wants to get access to something in BAR.E but
doesn't want to include BAR.E! This can happen when testing for the existance of
global function names that may not exist (routine_id() returns -1). To solve this
a variation of the 'export' statement might suffice...

  include bar.e
  export bar:fancy_rtn 
  include nat.e 

Now code in NAT.E can see 'fancy_rtn' that is global within the BAR.E tree.
Furthermore, the 'export' can be used to alias a global name ...

  include bar.e
  export bar:fancy_rtn as formatter
  include nat.e

Now code in NAT.E can see a symbol called 'formatter' that is actually the
global symbol 'fancy_rtn' defined within the BAR.E tree.

So, what you all think of these ideas ???

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell