1. Resurection of routine_id forward referencing
On the 9th December 2004, a feature in Eu2.5 alpha was discovered by Andy Serpa.
This was forward referencing of routine_id.
Rob saw this as a bug, and "fixed" it, despite pleas from others,
especially Derek Parnell, to leave it in. Since Eu is going "open source",
can this feature be reinstated? I imagine we will need the eu2.5a source,
and some coding skill that I don't have!
2. Re: Resurection of routine_id forward referencing
> This was forward referencing of routine_id.
> Rob saw this as a bug, and "fixed" it, despite pleas from others,
> especially Derek Parnell, to leave it in. Since Eu is going "open source",
> can this feature be reinstated? I imagine we will need the eu2.5a source,
> and some coding skill that I don't have!
I for one do see it as a bug. It breaks the top-down format of of
Euphoria. When I need jump back-and-forth between my code and
reference various routines from anywhere, I declare an integer for the
id of each routine I need at the very top of my code, then set that
integer to the id right after the end statement. Allowing one to see
"ahead" into the code breaks the core functionality of Euphoria. Let's
not start this debate again...
-- declare id integers
integer func2_id
function func1()
object i
i = call_func( func2_id, {} )
return 0
end function
function func2()
return 1
end function
func2_id = routine_id( "func2" )
3. Re: Resurection of routine_id forward referencing
Greg Haberek wrote:
>
> > This was forward referencing of routine_id.
> > Rob saw this as a bug, and "fixed" it, despite pleas from others,
> > especially Derek Parnell, to leave it in. Since Eu is going "open source",
> > can this feature be reinstated? I imagine we will need the eu2.5a source,
> > and some coding skill that I don't have!
>
> I for one do see it as a bug. It breaks the top-down format of of
> Euphoria. When I need jump back-and-forth between my code and
> reference various routines from anywhere, I declare an integer for the
> id of each routine I need at the very top of my code, then set that
> integer to the id right after the end statement. Allowing one to see
> "ahead" into the code breaks the core functionality of Euphoria. Let's
> not start this debate again...
>
> }}}
<eucode>
> -- declare id integers
> integer func2_id
>
> function func1()
>
> object i
>
> i = call_func( func2_id, {} )
>
> return 0
> end function
>
> function func2()
>
> return 1
> end function
> func2_id = routine_id( "func2" )
> </eucode>
{{{
>
>
Hi
Just adding to this. This is a very exciting time for eu, and there will be a
lot of changes, as poeple add there bits and pieces. There does need to be a
_loose_ organisational structure, but make it too restrictive, and people will
lose interest.
May I please ask that any changes people make retain backwards compatability.
I e if you add forward referencing for functions and procedures, then retain
the routine_id concept (frankly I like routine_id, but who am I to tell people
how to code) - you have the choice of whether to use it or not.
Similarly with goto - if you don't want to use it, don't, but if you do, you
can.
Personally, I would like a continue keyword! If I do ever get that, and someone
tries to run Eu with an old interpreter then what? So can we have a
VERSION_MAJOR
and a VERSION_MINOR global variable. And so on.
Interesting times ahead.
Chris
4. Re: Resurection of routine_id forward referencing
Sorry Greg, but I must disagree.
For myself, I would like have the ability to code things in the order
that I prefer - not the order that someone else decides is good
coding practice. Its the euphoria parsers job to figure it out - if
that means multiple passes through the code then so be it.
You can code the way you want - lets allow everyone that same liberty.
If my code is not pretty for someone else, too bad. Unless the someone else
is paying for my code and has stipulated the style up front - again, too bad.
I code things to get something done, not to teach coding style, so will
code in the way that makes the most sense for me.
IMHO, you are not "breaking the core functionality of Euphoria" since you
can do things the way you have always done. Old code still works,
therfore nothing is broken.
Its the simple principle: allow a coder to choose his own style, don't
enforce it. Thats my take on "goto" also.
Mail me privately if you want.
Cheers
Alan
5. Re: Resurection of routine_id forward referencing
> For myself, I would like have the ability to code things in the order
> that I prefer - not the order that someone else decides is good
> coding practice. Its the euphoria parsers job to figure it out - if
> that means multiple passes through the code then so be it.
> You can code the way you want - lets allow everyone that same liberty.
>
> If my code is not pretty for someone else, too bad. Unless the someone else
> is paying for my code and has stipulated the style up front - again, too bad.
> I code things to get something done, not to teach coding style, so will
> code in the way that makes the most sense for me.
Euphoria is designed to be interpreted from top to bottom. Any given
line of code may only reference code above it, not below. That is
simply how Euphoria operates. Top-to-bottom. If a line of code can
reference code below it, then this goes against how Euphoria operates.
That is why Rob considered it a bug and chose to not allow it.
If the current Euphoria code functionality doesn't comply with how you
code, then perhaps Euphoria isn't for you. It makes one pass over the
code and begins executing it from the beginning and stops at the
bottom.
> IMHO, you are not "breaking the core functionality of Euphoria" since you
> can do things the way you have always done. Old code still works,
> therfore nothing is broken.
True, it will still work the way it does, but if you're referencing
routines with routine_id and passing a code-generated sequence to it,
you may end up with a nasty bug that references code ahead of itself
or code it was never meant to reference at all.
> Its the simple principle: allow a coder to choose his own style, don't
> enforce it. Thats my take on "goto" also.
No goto, no forward referancing. Euphoria is designed to be simple. It
is simple. Features like goto are complicated and choppy. You can get
confused about where code jumps and where it comes from.
> Mail me privately if you want.
No need, I'm sure others would like to partake in this conversation as well.
6. Re: Resurection of routine_id forward referencing
Greg, I am aware of the top-to-bottom advantages and disadvantages.
However, if there is no compelling technical reason why this *must* be
enforced, then it should not be enforced. Particularly since it would have
taken Rob no effort to leave the bug/feature in.
The analogy for me is freedom of speech, or art appreciation.
Similarly ,I will decide for myself if Euphoria is for me or not.
I believe I have already voted with my wallet on that score,
being a paying customer since v1.4.
So I am afraid we will have to agree to disagree. OK?
7. Re: Resurection of routine_id forward referencing
Greg Haberek wrote:
>
> > For myself, I would like have the ability to code things in the order
> > that I prefer - not the order that someone else decides is good
> > coding practice. Its the euphoria parsers job to figure it out - if
> > that means multiple passes through the code then so be it.
> > You can code the way you want - lets allow everyone that same liberty.
> >
> > If my code is not pretty for someone else, too bad. Unless the someone else
> > is paying for my code and has stipulated the style up front - again, too
> > bad.
> > I code things to get something done, not to teach coding style, so will
> > code in the way that makes the most sense for me.
>
> Euphoria is designed to be interpreted from top to bottom. Any given
> line of code may only reference code above it, not below. That is
> simply how Euphoria operates. Top-to-bottom. If a line of code can
> reference code below it, then this goes against how Euphoria operates.
> That is why Rob considered it a bug and chose to not allow it.
>
> If the current Euphoria code functionality doesn't comply with how you
> code, then perhaps Euphoria isn't for you. It makes one pass over the
> code and begins executing it from the beginning and stops at the
> bottom.
>
> > IMHO, you are not "breaking the core functionality of Euphoria" since you
> > can do things the way you have always done. Old code still works,
> > therfore nothing is broken.
>
> True, it will still work the way it does, but if you're referencing
> routines with routine_id and passing a code-generated sequence to it,
> you may end up with a nasty bug that references code ahead of itself
> or code it was never meant to reference at all.
>
> > Its the simple principle: allow a coder to choose his own style, don't
> > enforce it. Thats my take on "goto" also.
>
> No goto, no forward referancing. Euphoria is designed to be simple. It
> is simple. Features like goto are complicated and choppy. You can get
> confused about where code jumps and where it comes from.
>
> > Mail me privately if you want.
>
> No need, I'm sure others would like to partake in this conversation as well.
>
>
Groan. Here we go again.
Chris
8. Re: Resurection of routine_id forward referencing
>
>
> > For myself, I would like have the ability to code things in the
> > order that I prefer - not the order that someone else decides is
> > good coding practice. Its the euphoria parsers job to figure it out
> > - if that means multiple passes through the code then so be it. You
> > can code the way you want - lets allow everyone that same liberty.
> >
> > If my code is not pretty for someone else, too bad. Unless the
> > someone else is paying for my code and has stipulated the style up
> > front - again, too bad. I code things to get something done, not to
> > teach coding style, so will code in the way that makes the most
> > sense for me.
>
> Euphoria is designed to be interpreted from top to bottom. Any given
> line of code may only reference code above it, not below. That is
> simply how Euphoria operates. Top-to-bottom. If a line of code can
> reference code below it, then this goes against how Euphoria operates.
> That is why Rob considered it a bug and chose to not allow it.
>
> If the current Euphoria code functionality doesn't comply with how you
> code, then perhaps Euphoria isn't for you. It makes one pass over the
> code and begins executing it from the beginning and stops at the
> bottom.
The interpreter can still make only one pass thru before execution,
and have forward referencing. I've suggested how to do this before:
if it's not resolved as a backwards reference, place it in a que, then
at the end attempt to resolve the que, when done resolving, dump
the que to the .err file.
Water is a option in lakes, but as people drown in it, i think it
should not be an option. Sheesh.
Kat
9. Re: Resurection of routine_id forward referencing
Kat wrote:
>
> Water is a option in lakes, but as people drown in it, i think it
> should not be an option. Sheesh.
If there's no water in your "lake," it's not a lake; it's just a hole. You
can't drive your boat in a hole.
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
10. Re: Resurection of routine_id forward referencing
- Posted by Jeremy Peterson <ptl99 at hotmail.com>
Sep 20, 2006
-
Last edited Sep 21, 2006
ChrisBurch2 wrote:
>
> Greg Haberek wrote:
> >
*snip*
>
> Groan. Here we go again.
>
> Chris
No, this should be fun to watch!(If a bit repetitive) Pass the popcorn please.
It's kinda a waste of time since at the rate we seem to be going everyone is
going to force Rob to take back his decision and make everything the way it's
always been. Sheesh...
Kat wrote:
>>
>> Water is a option in lakes, but as people drown in it, i think it
>> should not be an option. Sheesh.
> If there's no water in your "lake," it's not a lake; it's just a hole. You
> can't drive your boat in a hole.
> -=ck
But if it just hasn't rained in a while it's still a lake, but you call it an
"empty lake". And you could drive your boat in it if it was one of those
amphibious car-boat vehicles.:)
Jeremy
11. Re: Resurection of routine_id forward referencing
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Sep 20, 2006
-
Last edited Sep 21, 2006
Kat wrote:
>
> >
> > Euphoria is designed to be interpreted from top to bottom. Any given
> > line of code may only reference code above it, not below. That is
> > simply how Euphoria operates. Top-to-bottom. If a line of code can
> > reference code below it, then this goes against how Euphoria operates.
> > That is why Rob considered it a bug and chose to not allow it.
> >
> > If the current Euphoria code functionality doesn't comply with how you
> > code, then perhaps Euphoria isn't for you. It makes one pass over the
> > code and begins executing it from the beginning and stops at the
> > bottom.
>
> The interpreter can still make only one pass thru before execution,
> and have forward referencing. I've suggested how to do this before:
> if it's not resolved as a backwards reference, place it in a que, then
> at the end attempt to resolve the que, when done resolving, dump
> the que to the .err file.
For true forward referencing, you're correct. To get routine_id() to
use forward referencing is even more simple. routine_id() resolves the
routine id at run time. Since 2.5, run time comes after compile time,
so the interpreter has already parsed everything. This is why Rob had
to cripple routine_id() to get the same behavior out of it.
I think the already-existing loophole of routine_id() is all the excuse
that's needed to justify allowing routine_id() to forward reference.
Matt Lewis
12. Re: Resurection of routine_id forward referencing
- Posted by cklester <cklester at yahoo.com>
Sep 20, 2006
-
Last edited Sep 21, 2006
Jeremy Peterson wrote:
> Kat wrote:
> >>
> >> Water is a option in lakes, but as people drown in it, i think it
> >> should not be an option. Sheesh.
> > If there's no water in your "lake," it's not a lake; it's just a hole. You
> > can't drive your boat in a hole.
> > -=ck
> But if it just hasn't rained in a while it's still a lake, but you call it an
> "empty lake".
It is no longer a lake. There's no such thing as an empty lake. The very
definition of lake requires water. Otherwise, it's a hole.
Why the hell am I arguing this? LOL! :D
> And you could drive your boat in it if it was one of those amphibious
> car-boat vehicles.:)
Oh, yeah! Forgot about those! heh. :P
ONTOPIC: I hope RDS chooses the BSD license. I also hope we always have a
standard or official version of the code. (Is it possible to fork other
open source languages, like PHP or Python? I only ever hear about one version
of those.)
I don't care about the goto or forward referencing issues. But I do care when
somebody tries to convince me that a hole in the ground is a lake. :D
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
13. Re: Resurection of routine_id forward referencing
- Posted by Jason Gade <jaygade at yahoo.com>
Sep 20, 2006
-
Last edited Sep 21, 2006
cklester wrote:
>
> ONTOPIC: I hope RDS chooses the BSD license. I also hope we always have a
> standard or official version of the code. (Is it possible to fork other
> open source languages, like PHP or Python? I only ever hear about one version
> of those.)
>
> I don't care about the goto or forward referencing issues. But I do care when
> somebody tries to convince me that a hole in the ground is a lake. :D
>
> -=ck
> "Programming in a state of Euphoria."
> <a
> href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a>
You can fork PHP or Python or Ruby or whatever. The thing is is that each of
those languages has momentum behind them and most open-source development is a
strict meritocracy. You would have to prove something better about your fork than
the original.
Then again, changes could just as easily be folded back into the main project.
It is difficult, but not impossible, to fork open-source projects.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
14. Re: Resurection of routine_id forward referencing
- Posted by cklester <cklester at yahoo.com>
Sep 20, 2006
-
Last edited Sep 21, 2006
I want to thank Jason Gade for his explanation of forking and D. Newhall for
his explanation of the licenses. Thanks, guys! :)
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
15. Re: Resurection of routine_id forward referencing
- Posted by Jason Gade <jaygade at yahoo.com>
Sep 20, 2006
-
Last edited Sep 21, 2006
cklester wrote:
>
> I want to thank Jason Gade for his explanation of forking and D. Newhall for
> his explanation of the licenses. Thanks, guys! :)
>
> -=ck
> "Programming in a state of Euphoria."
> <a
> href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a>
You're welcome 
!
On this topic, I agree that routine_id() should allow forward referencing.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
16. Re: Resurection of routine_id forward referencing
- Posted by Al Getz <Xaxo at aol.com>
Sep 20, 2006
-
Last edited Sep 21, 2006
cklester wrote:
>
> Kat wrote:
> >
> > Water is a option in lakes, but as people drown in it, i think it
> > should not be an option. Sheesh.
>
> If there's no water in your "lake," it's not a lake; it's just a hole. You
> can't drive your boat in a hole.
>
> -=ck
> "Programming in a state of Euphoria."
> <a
> href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a>
Are you argueing pro or con here? ha ha.
We shouldnt go around making sure every lake has water just
so we can drive our boats in them.
Kat was making the point that just because people drown in lakes
doesnt mean we should empty every lake.
There is another side to this argument though, and that is
that that analogy isnt quite the same as forward referencing,
in that we also dont force people who are afraid of water
to swim in lakes. With forward referencing, we indirectly force
people to either use it or render our own coded handywork useless
to them. Thus, we force them to swim.
Personally, however, i dont see too much of a problem due
to the following argument:
Without forward referencing we already do this:
atom MyRid --sometime later in the code this gets filled
--using routine_id()
atom x
global procedure MyProc(atom a)
x=call_func(MyRid,{a})
end procedure
Ha ha! Notice we already have forward referencing?
In other words, we have the same 'problem' as with forward
referencing already, so adding forward referencing shouldnt
change anything in this respect.
Now again only with FR:
atom x
global procedure MyProc(atom a)
x=call_func(routine_id("MyFunc"),{a})
end procedure
Compare the two now. See the similarities?
We dont know where "MyFunc" resides with either one,
and that's really the main issue.
Now lets look at one more example with actual forward ref:
atom x
global procedure MyProc(atom a)
x=MyFunc(a)
end procedure
Compare all three. See any difference? No.
Thus, the argument is:
"Since we can already do it today there's no reason why
we shouldnt be able to do it tomorrow only a lot easier".
Yes, we force newbies to swim, but we already were doing that.
There is one difference, in that with actual FR we could do
this too:
--MyFile.exw
atom x
x=MyFunc(a)
but that still isnt 'that' different is it? Again, a resounding "No".
Again, actual f.r. isnt any different than 'emulated' f.r., which
we already have now.
Take care,
Al
E boa sorte com sua programacao Euphoria!
My bumper sticker: "I brake for LED's"
From "Black Knight":
"I can live with losing the good fight,
but i can not live without fighting it".
"Well on second thought, maybe not."
17. Re: Resurection of routine_id forward referencing
On Wed, 20 Sep 2006 13:54:58 -0700, Matt Lewis
<guest at RapidEuphoria.com> wrote:
>Kat wrote:
>>
>> The interpreter can still make only one pass thru before execution,
>> and have forward referencing. I've suggested how to do this before:
>> if it's not resolved as a backwards reference, place it in a que, then
>> at the end attempt to resolve the que, when done resolving, dump
>> the que to the .err file.
>
>For true forward referencing, you're correct. To get routine_id() to
>use forward referencing is even more simple. routine_id() resolves the
>routine id at run time. Since 2.5, run time comes after compile time,
>so the interpreter has already parsed everything. This is why Rob had
>to cripple routine_id() to get the same behavior out of it.
>
>I think the already-existing loophole of routine_id() is all the excuse
>that's needed to justify allowing routine_id() to forward reference.
I have done this but you should be aware it is not without problems:
http://palacebuilders.pwp.blueyonder.co.uk/pfeat.htm#forwardrefs
In particular there is a real "gotcha" with constants defined in what
I have called "The Danger Zone". Mostly the problems vanish if the
last line of the application is main() or WinMain(), but I think this
sort of thing is the reason why Rob has the philosophy he does and I
can easily imagine a newbie being, well outraged I think is the word
by this behaviour ("IT'S A ****ING CONSTANT!!!!").
There is a genuine fundamental problem here that cannot be solved by
adding more passes to the compiler - the only thing I can think of is
attaching a block of init code to each variable which is run if/when
it is referenced when still uninitialised, and I don't think I want to
go there.
Regards,
Pete
