1. Forward referencing
Hi
How much of a problem would it be to re introduce the bug that Rob squashed a
few years ago for eu 4 - ie calling functions and procedures after they
have been called? routine _id would still be unaffected, so no present code
would be broken. It may make includes a bit easier to implement.
Chris
2. Re: Forward referencing
ChrisBurch3 wrote:
>
> Hi
>
> How much of a problem would it be to re introduce the bug that Rob squashed
> a
> few years ago for eu 4 - ie calling functions and procedures after they
> have been called? routine _id would still be unaffected, so no present code
> would be broken. It may make includes a bit easier to implement.
>
> Chris
I don't see the necessity for this. It opens up all sorts of potential bugs.
This would be the proper method of forward referencing (which I use frequently).
integer r_Func2
function Func1( integer i )
return call_func( r_Func2, {2} )
end function
function Func2( integer i )
return i * 2
end function
r_Func2 = routine_id("Func2")
Could you post an example of how you could better implement the includes with
the bug reintrocuced?
-Greg
3. Re: Forward referencing
Greg Haberek wrote:
>
> ChrisBurch3 wrote:
> >
> > Hi
> >
> > How much of a problem would it be to re introduce the bug that Rob squashed
> > a
> > few years ago for eu 4 - ie calling functions and procedures after they
> > have been called? routine _id would still be unaffected, so no present code
> > would be broken. It may make includes a bit easier to implement.
> >
> > Chris
>
> I don't see the necessity for this. It opens up all sorts of potential bugs.
> This would be the proper method of forward referencing (which I use
> frequently).
>
Well, it didn't for 2-3 weeks until the 'bug' was noticed.
> }}}
<eucode>
> integer r_Func2
>
> function Func1( integer i )
> return call_func( r_Func2, {2} )
> end function
>
> function Func2( integer i )
> return i * 2
> end function
> r_Func2 = routine_id("Func2")
> </eucode>
{{{
>
>
Well, that may the 'proper' way of doing things, but
function Func1( integer i )
atom x
Func2(2)
end function
function Func2( integer i )
return i * 2
end function
is a lot easier. I guess C must have it wrong then.
> Could you post an example of how you could better implement the includes with
> the bug reintrocuced?
>
> -Greg
Weeeeeell, thats a bit more tricky, and probably more to do with lazy
programming than anything else
a.e
contains stuff
b.e
contains other stuff
main.exw
include a.e
include b.e
contains funcs called in both a and e
later on
b.e is edited to add a great function
then a.e is edited to call the great function in b.e - but it can't, because
its not in the right order. So you create routine ids, which is fine, but
its taken extra work to do it.
So, perhaps you could give an example of an introduced bug created by
forward referencing.
Chris
4. Re: Forward referencing
I believe that the bug referenced only applied to routine_id() calls, not
forward referencing in general.
Enabling code like this:
function Func1( integer i )
return call_func( routine_id("Func2"), {2} ) -- "Func2" not resolved until
called
end function
function Func2( integer i )
return i * 2
end function
I support this bug/feature for routine_id, not for general forward referencing.
I've heard that it would have helped writing Win32lib greatly.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
5. Re: Forward referencing
Hi
I've just a forum search for 'forward reference' Sorry, looks like
a got hornets nest, and may be too much trouble to re write the interpreter.
However, I'm still interested as to why allowing forward refs would
introduce bugs.
Is this not a simplistic view of how an eu progrom is interpreted.
1. stretch out all the files (includes etc) into one long program
2. build a table with all the variables (globals and locals) and functions
and procedures.
3. run the program with the addresses of the functions referenced
from the name table
if so, why not allow references to funcs and procedures that occur
later in the program list?
Chris
6. Re: Forward referencing
- Posted by CChris <christian.cuvier at ag?icult?re.gouv.fr>
May 01, 2008
-
Last edited May 02, 2008
Jason Gade wrote:
>
> I believe that the bug referenced only applied to routine_id() calls, not
> forward
> referencing in general.
>
> Enabling code like this:
>
> }}}
<eucode>
> function Func1( integer i )
> return call_func( routine_id("Func2"), {2} ) -- "Func2" not resolved until
> called
> end function
>
> function Func2( integer i )
> return i * 2
> end function
> </eucode>
{{{
>
> I support this bug/feature for routine_id, not for general forward
> referencing.
> I've heard that it would have helped writing Win32lib greatly.
>
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
In a project with hundreds of routines that may call one another in any order
and are hopefully split across a few files, imagine how tricky it is to position
routines so that they are seen by the includes that need them and appear after
any routine thta calls them.
You can do everything using routine_ids, but this accounted for a few dozens of
undocumented global symbols in previous versions of win32lib. I could clean up
that mess using the alternate w32routine_id, but:
* routine placement is just doable, not easily so
* any given large library has no need for a w32routine_id mechanism.
Forward referencing is not a problem at all: see Orac and my modified
interperter, for instance.
Additionally, backward referencing forces to write program upside down:
utilities first, then routines that call them, and on and on. I don't know about
you, but I usually read from top to bottom. This makes programs needlessly harder
to understand.
CChris
7. Re: Forward referencing
- Posted by CChris <christian.cuvier at agr?cu?ture.gouv.fr>
May 01, 2008
-
Last edited May 02, 2008
ChrisBurch2 wrote:
>
> Hi
>
> I've just a forum search for 'forward reference' Sorry, looks like
> a got hornets nest, and may be too much trouble to re write the interpreter.
>
> However, I'm still interested as to why allowing forward refs would
> introduce bugs.
>
> Is this not a simplistic view of how an eu progrom is interpreted.
>
> 1. stretch out all the files (includes etc) into one long program
> 2. build a table with all the variables (globals and locals) and functions
> and procedures.
> 3. run the program with the addresses of the functions referenced
> from the name table
>
> if so, why not allow references to funcs and procedures that occur
> later in the program list?
>
> Chris
Probably because of he various checks to be performed on exiting a file and on
completing parsing. That was the hardest part in implementing it.
routine_id(unheard_of_routine) should return -1, no problem with that either.
Perhaps it is the fright of and recoiling at... yes, spaghetti phantoms in the
code. I've never seen such coding, but perhaps I'm just too young.
CChris
8. Re: Forward referencing
- Posted by Jason Gade <jaygade at yahoo.c??>
May 01, 2008
-
Last edited May 02, 2008
CChris wrote:
>
> Jason Gade wrote:
> >
> > I believe that the bug referenced only applied to routine_id() calls, not
> > forward
> > referencing in general.
> >
> > Enabling code like this:
> >
> > }}}
<eucode>
> > function Func1( integer i )
> > return call_func( routine_id("Func2"), {2} ) -- "Func2" not resolved
> > until called
> > end function
> >
> > function Func2( integer i )
> > return i * 2
> > end function
> > </eucode>
{{{
> >
> > I support this bug/feature for routine_id, not for general forward
> > referencing.
> > I've heard that it would have helped writing Win32lib greatly.
> >
> > --
> > A complex system that works is invariably found to have evolved from a
> > simple
> > system that works.
> > --John Gall's 15th law of Systemantics.
> >
> > "Premature optimization is the root of all evil in programming."
> > --C.A.R. Hoare
> >
> > j.
>
> In a project with hundreds of routines that may call one another in any order
> and are hopefully split across a few files, imagine how tricky it is to
> position
> routines so that they are seen by the includes that need them and appear after
> any routine thta calls them.
If the program is factored correctly then I disagree.
> You can do everything using routine_ids, but this accounted for a few dozens
> of undocumented global symbols in previous versions of win32lib. I could clean
> up that mess using the alternate w32routine_id, but:
> * routine placement is just doable, not easily so
> * any given large library has no need for a w32routine_id mechanism.
>
> Forward referencing is not a problem at all: see Orac and my modified
> interperter,
> for instance.
>
> Additionally, backward referencing forces to write program upside down:
> utilities
> first, then routines that call them, and on and on. I don't know about you,
> but I usually read from top to bottom. This makes programs needlessly harder
> to understand.
>
> CChris
Again, I disagree here too. Yes, I read from top to bottom usually, but I know
that in most programming languages the object is to find the main routine (or the
file containing the main routine) and start there.
I don't remember the reasons now, but I remember Rob had pretty good reasons for
not having general forward-referencing. I think that I'll stick with that. After
all, he's the one with the degree, not me.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
9. Re: Forward referencing
- Posted by c.k.lester <euphoric at ?klest?r.com>
May 01, 2008
-
Last edited May 02, 2008
CChris wrote:
>
> In a project with hundreds of routines that may call one another in any order
> and are hopefully split across a few files, imagine how tricky it is to
> position
> routines so that they are seen by the includes that need them and appear after
> any routine thta calls them.
I can tell you it's a pain in the brain. BBCMF uses TONS of include files
(modularization, dontcha know), and I have sometimes had to jostle them
around, or move funcs/procs to a more appropriate location.
Having said that, I don't need forward referencing. I like the define-it-
before-you-use-it approach. It's intuitive to me, now. :/
