1. Let's talk about scope
- Posted by Alan Tu <ATU5713 at COMPUSERVE.COM>
Jan 17, 1999
-
Last edited Jan 18, 1999
This anecdote will demonstrate the problem, which Ralf actually brought u=
p
a few days ago. I balked at first, but now I totally see the point.
I was trying to convert Language Wars v2.1 alpha into a game that had WAV=
files. The first thing I did was to make the torpedo firing play a WAV
file I have, using Jacques Deschenes sfx2.e file. Guess what? There wer=
e
compile-time conflicts due to conflicting global types and constants. So=
I
started to hack the various includes. Three changes later, I got a
run-time error, which I was unable to diagnose because I'm not registered=
. =
I'm sure I probably could have made this work, but I just gave up.
Ralf's suggestion was to change the scope rule to allow routines in deep
includes inaccessible. This would solve my problem, but create others. =
I
think I have included graphics.e file. I know it includes machine.e. So=
,
in my main file, I call machine.e files without directly including it. I=
am exploiting the scope rules. If this new scope rules is implemented, a=
ll
such programs would no longer work.
It seems to me that the first priority should be portability. Currently,=
the scope rules do not allow portability. This is bad. But, what would =
be
the new scope rules? Are we ready to make hundreds of programs un-runnab=
le
without hacking it? In deeply nested and complex includes, this could
cause inefficient code. On the other hand, this could certainly lead to
more discipline. Perhaps this should be dynamicly turned on and off. An=
y
thoughts, Robert (or anyone else?)
Alan
=
2. Re: Let's talk about scope
At 11:44 p.m. 17-01-99 -0500, you wrote:
>Ralf's suggestion was to change the scope rule to allow routines in deep
>includes inaccessible. This would solve my problem, but create others. I
>think I have included graphics.e file. I know it includes machine.e. So,
>in my main file, I call machine.e files without directly including it. I
>am exploiting the scope rules. If this new scope rules is implemented, all
>such programs would no longer work.
But you can fix it with a simple include xxx.e
If you follow the library reference there says wich include file contains a
particular routine.Following that guideline there should be NO side
effects.
I totally agree that a more complete namespace mechanism should be
implemented. I particulary like Turbo/Object Pascal unit aproach. Just
name each include file, if there is an identifier conflict you can specify
the include file you actually mean to address. Example:
include myfile.e
integer x
x = myfile.x + 10 -- x is declared in myinclude.e as global
or
include myfile.e
integer x
x = (x in myfile) + 10
About prohibiting nested include files a solution would be:
include this.e -- Can't get accessed out of this module
global include that.e -- Can get accessed out of this module
Regards,
Daniel Berstein
daber at pair.com
3. Re: Let's talk about scope
- Posted by CHARN1407 at AOL.COM
Jan 18, 1999
i'm currently working on a rather large project which has, at the moment, 21
include files, which have many conflicts. My solutions was to first include a
vars.e which had all global variables and types (i figure types with the same
name have the same definition...). Then i took out all the includes in
include files and included them in the main program above their callers.
After removing all local types and includes in the include files, i had a
grand total of 1 naming conflict (upper defined in both sfx2.e and
wildcard.e). The disadvantage: everything is pretty much global. So what;
it already is. The advantage: no conflicts. The program runs fine.
something to think about
CHARN
4. Re: Let's talk about scope
>i'm currently working on a rather large project which has, at the moment,
21
>include files, which have many conflicts. My solutions was to first
include a
>vars.e which had all global variables and types (i figure types with the
same
>name have the same definition...). Then i took out all the includes in
>include files and included them in the main program above their callers.
>After removing all local types and includes in the include files, i had a
>grand total of 1 naming conflict (upper defined in both sfx2.e and
>wildcard.e). The disadvantage: everything is pretty much global. So
what;
>it already is. The advantage: no conflicts. The program runs fine.
You've reordered the entire project, including all include-files.
>something to think about
I did. It looks like a lot of messy work to me. And it reminds me of basic.
Anyone should feel free to say that re-ordering huge projects, and having
special versions of each library, is fun to do. I disagree though.
Ralf
5. Re: Let's talk about scope
Alan Tu wrote:
> This anecdote will demonstrate the problem, which Ralf actually brought up
> a few days ago. I balked at first, but now I totally see the point.
>
> I was trying to convert Language Wars v2.1 alpha into a game that had WAV
> files. The first thing I did was to make the torpedo firing play a WAV
> file I have, using Jacques Deschenes sfx2.e file. Guess what? There were
> compile-time conflicts due to conflicting global types and constants. So I
> started to hack the various includes. Three changes later, I got a
> run-time error, which I was unable to diagnose because I'm not registered.
> I'm sure I probably could have made this work, but I just gave up.
>
> Ralf's suggestion was to change the scope rule to allow routines in deep
> includes inaccessible. This would solve my problem, but create others. I
> think I have included graphics.e file. I know it includes machine.e. So,
> in my main file, I call machine.e files without directly including it. I
> am exploiting the scope rules. If this new scope rules is implemented, all
> such programs would no longer work.
>
> It seems to me that the first priority should be portability. Currently,
> the scope rules do not allow portability. This is bad. But, what would be
> the new scope rules? Are we ready to make hundreds of programs un-runnable
> without hacking it? In deeply nested and complex includes, this could
> cause inefficient code. On the other hand, this could certainly lead to
> more discipline. Perhaps this should be dynamicly turned on and off. Any
> thoughts, Robert (or anyone else?)
>
> Alan
>
Well, I think the way the scope is set up is cool and all, but you, and
everyone else is right about naming conflicts. I think there should be two
syntaxes for the "include" keyword..
1) include filename
2) include filename local
Syntax 1 would run like it has been running in all versions of Euphoria, so
programmers wouldn't have to change their code around.
But with syntax 2, if file A included file B, the code for file B would run,
but all symbols declared as "global" can only be used by file A. Any other
file wouldn't be able to use the global symbols. If file B was then later
included with either syntax, the code wouldn't run again, but the global
symbols would be usable, depending on the rules of the syntax.
Another thing that would be pretty cool would be routine overloading. For
example:
-- Routine overloading example (Win32) --
--
-- This is just an example,
-- There is no error checking, so
-- this way, my point can be explained
-- much more clearly.
--
-- Includes --
include dll.e
-- Constants --
constant
-- Open the user32.dll file --
user32 = open_dll("user32.dll"),
-- Define a function --
xSendMessage = define_c_func(user32, "SendMessageA", {C_UINT, C_UINT,
C_UINT, C_LONG}, C_LONG)
-- SendMessage as a procedure --
procedure SendMessage(atom hWnd, atom uMsg, atom wParam, atom lParam)
if c_func(xSendMessage, {hWnd, uMsg, wParam, lParam}) then
end if
end procedure
-- SendMessage as a function --
function SendMessage(atom hWnd, atom uMsg, atom wParam, atom lParam)
return c_func(xSendMessage, {hWnd, uMsg, atom wParam, atom lParam})
end function
--
-- Let's just pretend the Win32 constants and all of
-- the other functions are defined.
--
-- Call the SendMessage procedure --
SendMessage(HWND_DESKTOP, WM_PAINT, GetDC(HWND_DESKTOP), 0)
-- Call the SendMessage function --
if SendMessage(HWND_DESKTOP, WM_PAINT, GetDC(HWND_DESKTOP), 0) then
puts(2, "Hey there!\n")
end if
-- End of example --
If this feature was implemented, function overriding should also be supported.
All you would have to do is declare the routine the EXACT same way as the
previous one. Yes, I know you're all asking, "But how will we be able to call
the old routine?" Simple! Use routine_id()! Example:
-- The example --
-- useless #1 --
procedure useless(sequence s)
for count = 1 to length(s) do
puts(2, s[count] & '\n')
end for
end procedure
-- Afraid of losing it? Let's get it's ID.. --
integer id
id = routine_id("useless") -- Hahaha.. Now we've gotcha. --
-- Call the routine --
useless("Hey hey hey!")
-- useless #2 --
procedure useless(sequence s)
puts(2, s & '\n')
end procedure
-- Call the routine --
useless("Hey hey hey!") -- See the difference? --
-- Let's call the old routine. --
call_proc(id, {"Hey hey hey!"})
-- End of example --
Well, I don't know about everyone else, but, I think it rocks. But the reason
why I think it would be hard to implement would be because it's quite hard to
tell most integers from most atoms (when they're whole numbers), so the
interpreter won't know which routine to call.
As far as overriding constants and variables, I think that would rock. Just
define the variable with the same name. Simple as that. The only disadvantage
would be that there's no way to manipulate the old variable, unless you used
syntax 2 of the include keyword (which hasn't been implemented).
If anyone wants, they can email me at this address, or afterbeat at hotmail.com
The AfterBeat
6. Re: Let's talk about scope
On Mon, 18 Jan 1999 00:42:04 EST, CHARN1407 at AOL.COM wrote:
>i'm currently working on a rather large project which has, at the moment, 21
>include files, which have many conflicts. My solutions was to first include a
>vars.e which had all global variables and types (i figure types with the same
>name have the same definition...). Then i took out all the includes in
>include files and included them in the main program above their callers.
>After removing all local types and includes in the include files, i had a
>grand total of 1 naming conflict (upper defined in both sfx2.e and
>wildcard.e). The disadvantage: everything is pretty much global. So what;
>it already is. The advantage: no conflicts. The program runs fine.
>
>something to think about
It seems like:
1. A lot of work to change Jiri's font.e and Pete's mighty.e and
Dave's text-gui library just to avoid conflicts.
2. What happens when Jiri or Pete or ? decides to make improvements
in their package? Now my program is broken.
3. What happens to people who download my changed font.e or mighty.e,
which overwrites their standard file of the same name, breaking
all their other programs?
Irv
7. Re: Let's talk about scope
- Posted by CHARN1407 at AOL.COM
Jan 18, 1999
Irv writes:
>>>>>>It seems like:1. A lot of work to change Jiri's font.e and Pete's
mighty.e and Dave's text-gui library just to avoid conflicts.
not much, types and includes are few and at the top of files
>>>>>2. What happens when Jiri or Pete or ? decides to make improvements
in their package? Now my program is broken.
>>>>>>>3. What happens to people who download my changed font.e or mighty.e,
which overwrites their standard file of the same name, breaking
all their other programs?
valid points, but what else am i supposed to do (besides wait for EU 2.2 to
come out)? I prefer to take 10 minutes now and some upkeep now and then to
organize everything than wait for improvements in the language
CHARN
