OpenEuphoria

Re: confusion about include

• Posted by mattlewis (admin) Aug 07, 2010
• 1319 views

This is not quite correct. Global symbols are still global. However, the way in which we resolve these symbols has changed. Global symbols not in the current file's include tree will not be resolved until the end, and will be effectively hidden by other symbols in the include tree with the same name. When you include a file, you have access to all symbols in that file. In some circumstances, we find that two files include each other.

Consider the following code:

-- file a.e 
include b.e 
export integer foo 
bar() 
 
-- file b.e 
include a.e 
foo = 1 
export procedure bar() 
    ? foo 
end procedure 
 

Here we have two files that include each other. In v3, this code wouldn't work, because the parser starts reading b.e as soon as it hits the first include statement. So when b.e tries to use foo, we get an error, because foo hasn't been declared yet.

But in v4, as I said, you have access to all symbols in any file you include, so it's perfectly fine to use foo from b.e.

Now, it's important to consider the way in which symbols are resolved. Euphoria prefers (and IIRC, this started in v3.1) to use a symbol that is in a file that has been included (directly or indirectly) from the file in which you're trying to use it. The main purpose for this is to help with using multiple 3rd party libraries. The net effect to the coder is that so long as he includes the files he wants to use, he shouldn't have to worry too much about getting symbol clashes. And if he does, he can use namespaces to make sure that he uses the right symbols.

When you follow this thought to global symbols, it becomes clear that if we find a matching global symbol that hasn't been included directly or indirectly by the current file, we still don't know that this is the correct symbol, because we may not have finished parsing all of the files that have been included by the current file. So we wait to fully resolve this until we're finished. This can also slow down parsing if your code relies on globals that haven't been included.

This makes developing euphoria a lot more difficult, but using it easier. The cost to you as the end user is that you'll probably have to write more include statements, but you should never have to rearrange the order of declarations and include statements to get everything to work out (though you still might occasionally need namespaces).

Matt