OpenEuphoria

Re: Euphoria Interpreter design

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Feb 25, 1999
• 460 views

While I see the validity of the argument, I've got a couple of minor =
concerns...

How about adding a new scope level entirely, "inclusive"? An inclusive =
constant/variable/routine would be available:

   -- within the file, similar to local
   -- within any other file that *specifically* chooses to include the =
file
   -- NOT within any other files that do not *specifically* include the =
file

It seems to match the kind of modified-global scope that's most wanted.

I suggest this only because I'm not quite sure that the global scope =
should be tossed out completely, and the identifier "global" bests suits =
the declaration of that scope. (However, I admit that once an =
"inclusive" scope were introduced, it would seriously diminish the role =
of the global scope; I suppose the global scope would then not even =
*really* be needed. But even if it were eliminated, I would prefer the =
new scope to have a name change. "global" should mean global.)

As to the mutually-callable include files... I've run into problems =
there myself; I don't see how a scope change addresses it though. Even =
if it fit the example below, the new scope wouldn't necessarily have to =
allow mutual inclusion--if that were the case, the global scope should =
be able to do it. I would think that mutual inclusion isn't allowed =
soley to enforce declare-before-use, not as a side effect of the current =
global scope rules.

I haven't decided yet if I want to see a break in the declare-before-use =
design in order to allow mutual inclusion, or for any other reason... =
both positions have strong points.


Rod Jackson

----------
From:   Lucius Hilley III[SMTP:lhilley at CDC.NET]
Sent:   Thursday, February 25, 1999 2:18 PM
To:     EUPHORIA at LISTSERV.MUOHIO.EDU
Subject:        Re: Euphoria Interpreter design

On Thu, 25 Feb 1999 07:35:28 +0100, Ralf Nieuwenhuijsen =
<nieuwen at XS4ALL.NL>
wrote:

>
>Btw, Robert, considering this, wouldnt it be able to routine_id () a
global or local variable and/or constant and have it work
>like a function (with zero arguments) ?
>
>Nevertheless, im not convinced. I still want mutally callable include
files. I dont mind a forced linear order *within* the
>include file. (local scope only thus).
>
>Ralf

I agree here.  I don't feel this is an issue of =
define-it-before-you-use-it.
I feel this is a scope issue that should have been cleared up long ago.
IE:
--   image.e    --
include graphics.e
--CODE

-- MyProgram --
include custom.e
include image.e

--image.e has access to custom.e global routines, variables and =
constants.
--ALSO
-- MyProgram has access to all of graphics.e global routines and =
variables.

I feel that image.e should not have access to custom.e globals
I also feel that I MyProgram should not have access to graphics.e =
globals.

This is clearly and issue of scope. I feel that access to globals of an
include file should only be available to the code that implicitly =
included
the file.

        Lucius L. Hilley