Re: Euphoria Interpreter design, Rob?
Okay. I agree. That in my examples I didn't cover how a better scope
set SHOULD effect mutual inclusion.
RECAP:
I feel that the scope should be that globals are only accessable the
program or include file that implicitly included that file.
CODE:
--inc1.e--
include inc2.e
global procedure line_puts(sequence s)
if text(s) then
puts(1, s & '\n')
end if
end procedure
procedure
-------------------------
--inc2.e--
include inc1.e
global type text(sequence s)
sequence temp1, temp2, textchars
textchars = "0123456789" &
"ABCDEFGHIJKLMNOPQRSTUVWXYZ" &
"abcdefghijklmnopqrstuvwxyz" &
"! at # $%^&*()[]{};:<>,./?+=-_\\\"\'"
temp1= s * 0
temp2 = temp1 + 1
for A = 1 to length(textchars) do
temp1 = temp1 + (s = textchars[A])
end for
return compare(temp1, temp2)=0
end type
global procedure message(sequence s)
line_puts(s)
end procedure
------------------------
The reason the above should be possible is simple. Assume that the
2 inclusions above are considered implicit inclusions. Then you
know that this implicit rule implies that inc1.e has access to inc2.e
and you see that inc2.e includes inc1.e but inc1.e can't see that
inc2.e has included inc1.e and doesn't have access to inc1.e globals
because of it isn't implicitly included, But it has access to inc1.e
globals because it IS inc1.e.
The same is true of inc2.e. This is how mutual recursion SHOULD be
possible. This would allow for some tricks that wouldn't require
routine_id() for mutual recursion. Just use two seperate include files
for the routines that call each other. The define-it-before-you-use-it
would remain intact. It would be defined before use. Just mutually so.
I feel this would have been the elegant way around routine_id().
I do however feel that routine_id() still has its uses. I just don't
feel the use should be mutual recursion. IE: routine_id() could make
for an excellent code testing program.
Rob, Maybe we should have something like the following possible.
BTW, I know it probably wouldn't be easy to implement.
CODE:
--image.e--
include graphics.e
-----------
--custom.e--
implicit include special.e
-- or maybe
restricted include special.e
-- or possibly
local include special.e -- I think I like local the best.
-----------
--Program.ex--
include custom.e
include image.e
--------------
Now the scope should be that Program.ex has access to custom.e but not
special.e, and that Program.ex has access to both image.e and graphics.e
On Fri, 26 Feb 1999 07:28:16 +0100, Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
wrote:
>>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.
>
>Mutual inclusion wouldnt be able with the current scope or it would mean,
that when you define something 'globally' in your
>file, its also mutually accesable from within that file. Something it
appears almost nobody wants. But I do want mutual
>inclusion is such way its routines can mutually call the routines of the
files it includes. If you include it, it should appear
>as if the code was included at that point. Without that, include files are
not more than an illusion of seperate parts of your
>program. You should simply not be able to modify what the include file
sees, unless by modifying things it actually included.
>Thats the real and whole concept behind 'seperate' part of code, the
idealogy behind an include file, I hope.
>
>> 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.
>
>Surely, I understand the points of linear order *within* an include file,
but Im extremely curious how many of those points hold
>up when include files are the issue.. eh.. none.
>
>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
|
Not Categorized, Please Help
|
|
