1. Forward referencing
- Posted by ChrisBurch3 <crylex at ?ma?l.com> May 01, 2008
- 655 views
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
- Posted by Greg Haberek <ghaberek at ?mail.com> May 01, 2008
- 632 views
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
- Posted by ChrisBurch2 <crylex at fr?e?k.co.uk> May 01, 2008
- 647 views
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
- Posted by Jason Gade <jaygade at yaho?.c?m> May 01, 2008
- 652 views
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
- Posted by ChrisBurch2 <crylex at freeuk.co.??> May 01, 2008
- 643 views
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
- 635 views
- 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
- 654 views
- 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
- 643 views
- 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
- 658 views
- 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. :/