OpenEuphoria

1. Forward reference to included function

• Posted by ArthurCrump Jan 13, 2014
• 1731 views

The manual for Euphoria 4.0.5 states that:

The scope of all procedures, functions and types, which do not have a scope modifier, starts at  
the beginning of the source file and ends at the end of the source file in which they are declared.  
In other words, these can be accessed by any code in the same file. 

any_key("\nChoose a key and press it\n") 
include std/console.e 

Are forward references intended to find routines in include files or was it intended that the routine should be in the same file as stated in the 4.0.5 documentation?

Arthur

3. Re: Forward reference to included function

• Posted by mattlewis (admin) Jan 13, 2014
• 1686 views

The scope of all procedures, functions and types, which do not have a scope modifier, starts at  
the beginning of the source file and ends at the end of the source file in which they are declared.  
In other words, these can be accessed by any code in the same file. 

any_key("\nChoose a key and press it\n") 
include std/console.e 

Yes! The bit you quoted was about things without a scope modifier. You'll never see them from another file. Stuff in other files is available, period, if you've included the file. You don't have to carefully arrange code so that files can reference each other. You can safely put all of your includes at the top, instead of hiding them inside your code.

Matt

5. Re: Forward reference to included function

• Posted by _tom (admin) Jan 13, 2014
• 1659 views

The location of the the include statement is important!

A variable originating in an include file will be visible, in the including file, only from the point of the include statement to the end of the file--but not anywhere before the include statement.

For a procedure or function this restriction does not apply; if you only use routines from an include file (most of the time) then you have full freedom where the include statement is written.

This is why the single term introduce is better than define and declare. Knowing where a variable is defined does not help you understand the full range of scope when there are included files. If you try to use a constant in the std/mathcons.e module and forget to include it then you get an error. If you do include std/mathcons.e the variable is only in scope from the point of introduction, that is the include statement.

The term introduce is simpler and more universal. The same description for scope applies to one file and a set of nested include files.

_tom

7. Re: Forward reference to included function

• Posted by _tom (admin) Jan 13, 2014
• 1662 views

The module (aka included file):

-- test.e  
export object foo = 1  

The main file (aka the including file):

-- test.ex  
 
? foo 
  --^ I added this line to illustrate the "introduce" concept 
 
? object( foo )  
procedure bar()  
    ? foo  
end procedure  
  
include test.e  
  
bar()  

My result:

 
$ eui test.ex 
 
test.ex:3 
variable foo has not been assigned a value 
 
 
--> See ex.err  

My conclusion: the variable foo has not been "introduced" because the include statement comes after the ? foo statement. But foo has been properly "declared" within the module.

declare

often used to "declare a variable"

define

sometimes specific to "define a routine"

declare, define

sometimes used to mean the same thing, by the same author

_tom

9. Re: Forward reference to included function

• Posted by mattlewis (admin) Jan 13, 2014
• 1659 views

-- that means variable x has not been "introduced" (since two steps needed...declare and assign) 

Sorry, I don't think this clarifies anything. It just introduces another term. I think it is less clear and will lead to more confusion.

Matt

11. Re: Forward reference to included function

• Posted by petelomax Jan 14, 2014
• 1629 views

Somewhat offtopic, but I thought I'd share a little about the situation in Phix.

Suppose you have

  -- file1.e 
  include file2.e 
  f1p() 

and

  -- file2.e 
  include file1.e 
  global procedure f1p() 
  end procedure 

Now, if main.exw includes file1.e then everything is resolved cleanly, however if main.exw includes file2.e, then the compiler hits EOF in file1.e before (the second half of file2.e is processed and) f1p is actually declared, which generates a compilation error. (Feel free to giggle at this point!) In Phix, f1p() is an implicit call and therefore local, not global, though it can get automatically promoted to global, if found "in time". In Phix, you need an explicit "forward global procedure f1p()" at the top of file1.e to get round this (or include the root of the tree, rather than start with one of the branches). Also (cue more giggling) Phix does not permit forward variable references, period, which has never bothered me in the slightest.

Anyway, I did actually have something possibly useful to say:

In Phix, integer (and more recently pure literal constant) assignment on declaration effectively occurs at compilation time leading to forward-safe code looking like:

integer xinit = 0 
sequence table 
global procedure x() 
   if not xinit then 
      table = repeat(0,200) 
      xinit = 1 
   end if 
   ... 
end procedure 

So no matter how you invoke x(), the (integer) variable xinit never suffers one of those pesky "has not been assigned" errors.

Regards, Pete

13. Re: Forward reference to included function

• Posted by _tom (admin) Jan 15, 2014
• 1552 views

Does this explaination make sense? By the time you get to the last line Arthur's question gets answered...

_tom

The scope of an identifier is "the region of source-code where the identifier can be used."

Any One File

If you examine any one source-code file:

• For an object (variable, constant, enum) you can declare and define the identifier on different lines or you can declare and define in one statement. The scope of the object is from the definition to the end of the source-code file.

• For a routine (procedure, function, type) you declare and define the identifer when you write structure of the routine. The scope of a routine is for the entire source-code file (top to bottom.) Notice that a routine is in scope within the structure of the routine--this is why you can write recursive routines.

A scope modifier (export, public, global) preceding the declaration of an identifer has no impact on the scope within the single source-code file.

Any Two Files

A primary file is "the file doing the including." A module file is "the file being included."

The file extension ( .ex or .e ) has no impact on how including and included files behave. You will see an included file described as an "include", a "module", or a "library." The standard library files can be described as modules that are included by your program.

No Scope Modifier

When File A (the primary file) includes File B (the module file) the following properties apply:

• The top-level statements of the module will be executed when included by the primary file.
• All module file identifiers will be invisible to the primary file.
• All primary file identifiers will be invisible to the module file.
• A module is physically included in the primary file only once; if you repeat an include statement it is quietly ignored.

With Scope Modifier

Only identifiers with a scope modifier (export, public, global) declared in a module will be visible to the primary file.

When you include a module with a scope modified identifier that identifier has the scope properties of a locally declared identifier. In the primary file:

• The possible scope of an object (variable, constant, enum) is from the include statement to the end of the primary file. As always, an object has to be defined (assigned a value) before you may use it.
• A routine (procedure, function, type) will be in scope for the entire file (top to bottom).

Forward Reference

A forward reference is "when you use an identifier that is declared later in the source-code than the statement you are writing."

For an object (variable, constant, enum) no forward references are possible. You must always declare and define an object before you may use it.

For a routine (procedure, function, type) forward references are possible because the scope of a routine is for the entire source-code file (top to bottom).

15. Re: Forward reference to included function

• Posted by _tom (admin) Jan 15, 2014
• 1542 views

I was seeing "defined" as a variable after being assigned a value. But, since you can use atom(x) before an assignment I now understand how we just need "declared".

This probably means I can do a search and replace on all (most) occurances of "define" in the documentation and replace them with "declare".

This simplifies the first diagram.

This I don't understand:

It suggests to me that this should work:

foo() 
procedure foo() 
 ? x 
end procedure 
atom x = 1 
-- variable x has not been assigned a value  

But what actually works is:

atom x = 1 
foo() 
procedure foo() 
	? x 
end procedure 

Creating a diagram to explain nested scopes is going to take some work.

_tom

17. Re: Forward reference to included function

• Posted by evanmars Jan 16, 2014
• 1520 views

foo() 
procedure foo() 
 ? x 
end procedure 
atom x = 1 
-- variable x has not been assigned a value  

If I may comment as someone that isn't that great of a programmer and relies heavily on the documentation to understand how Euphoria is supposed to work.

I think the point is is that the variable is definitely in scope; it can be written to, but it cannot be read from until it has first been written to.

Is this correct?

19. Re: Forward reference to included function

• Posted by jaygade Jan 16, 2014
• 1523 views

It is a little unintuitive, since constants work one way and variables another.

If a change in behavior is desired to make variable combined declaration and assignment work like constant declaration and assignment, I would suggest putting in a feature request ticket.

At a minimum, the behavior should be documented.