OpenEuphoria

Namespace Proposal

• Posted by Robert Craig <rds at RapidEuphoria.com> Jun 22, 2001
• 448 views

Here's what I'm planning to do in 2.3 about 
the so called "namespace problem".

* First, what is the problem?

In Euphoria, as in all programming languages,
naming conflicts can occur. To reduce these conflicts,
there are mechanisms to reduce the scope of names. 
For example, in Euphoria we basically have three
different scopes for user-defined names:

private - visible only within a routine

local - visible only within a file (after the point of declaration)

global - visible everywhere (after the point of declaration)

To keep things simple, we'll ignore keywords, built-in routines, 
and loop variables. 

This lets you for example, have a private variable x
in one routine, and a private variable x in another
routine, and the two are understood to be different variables.
There is no naming conflict. You can also have a private
variable x, and a global or local variable x.
No problem.

The main problems that have occurred have been with
global symbols. Because they are visible everywhere
(after they are declared), they tend to cause conflicts.

For example, if I add some new global routines or variables
to the standard Euphoria includes, it is very likely that I
will break someone's code, since someone is likely to have
already declared the same symbol in their program. For example,
if I were to add an abs() function to misc.e, it would conflict
with similar abs() functions declared globally and locally in
many people's code.

Similarly, if you try to use two large libraries (include files)
written by different people, there's a chance that a global
symbol in one will conflict with a global or local symbol
in the other. If you have the source, you can edit one of the 
includes, but when the author comes out with a new version,
you'd have to re-edit it each time. Not very convenient.

* A solution

To alleviate this situation, I propose:

1. Let a local symbol override a global symbol with 
    the same name for the duration of the scope 
    of the local symbol. This is logical when you consider that 
    private variables already override local and global symbols.
    This change alone would greatly reduce the number of conflicts.

2. Allow multiple globals with the same name to 
    coexist in a program. When you reference
    a global you can use its filename as a
    qualifier. e.g.
            graphics.text_color(RED) 

     Some have proposed a new syntax such as:

            include graphics.e as gr

            gr.text_color(RED)

      where you get to invent a new name, rather than
      rely on the filename. filename's aren't really nice to use,
      since on Windows they are case-insensitive. 
      Also you might have graphics.e and graphics.ew in the 
      same program. Or for that matter, graphics.xyz

      I think that introducing a new name would cause confusion. 
      Everyone would make up his own new name,
      and people would have trouble reading each other's code.

      This syntax can be taken further, allowing variations on the include
      mechanism to achieve finer control over what symbols are
      part of what namespace. I think in a simple language like
      Euphoria, we don't need to create a highly-sophisticated 
      namespace mechanism. 

I can see one special case where this proposal will break 
existing code. e.g.

integer x

include foo.e
     .......... global integer x

x = 99 -- which x?

Currently, the x declared in foo.e will be set to 99.
Under the new proposal, the x at the top of the 
main file will be set. I believe this case is extremely rare.

Any suggestions?

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com