1. Secret new routine_id() feature. (Attn: Rob)
I just noticed that in v2.5, routine_id() can now "see ahead" and give you
routine numbers for functions occuring below in the code or in files including
after the current one (if the routine is global). This new ability is not in the
release notes, and the docs for routine_id() still say the routine must be
"visible" to get the routine number.
I assume this stems from the fact that all the code is now parsed in advance.
While this is a welcome change, it begs the question: why not now allow full
forward referencing and let us call routines defined below in the code directly?
[ Rob: if you actually did not know of this new ability, which I suspect since
it is not mentioned anywhere, please leave it that way. ]
2. Re: Secret new routine_id() feature. (Attn: Rob)
Andy Serpa wrote:
>
>
> I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> routine
> numbers for functions occuring below in the code or in files including after
> the current
> one (if the routine is global). This new ability is not in the release notes,
> and
> the docs for routine_id() still say the routine must be "visible" to get the
> routine
> number.
Halleluyah! I can confirm this.
> I assume this stems from the fact that all the code is now parsed in advance.
> While
> this is a welcome change, it begs the question: why not now allow full forward
> referencing
> and let us call routines defined below in the code directly?
Very welcome and very useful.
> [ Rob: if you actually did not know of this new ability, which I suspect since
> it is
> not mentioned anywhere, please leave it that way. ]
This is not a bug, it really is a feature :D
Please leave it in, pretty please with sugar on top! I'm already
using it.
<sings>
Oh happy days, ...
</sings>
--
Derek Parnell
Melbourne, Australia
3. Re: Secret new routine_id() feature. (Attn: Rob)
Andy Serpa wrote:
>
>
> I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> routine
> numbers for functions occuring below in the code or in files including after
> the current
> one (if the routine is global). This new ability is not in the release notes,
> and
> the docs for routine_id() still say the routine must be "visible" to get the
> routine
> number.
>
> I assume this stems from the fact that all the code is now parsed in advance.
> While
> this is a welcome change, it begs the question: why not now allow full forward
> referencing
> and let us call routines defined below in the code directly?
That would definatly help eliminate some of the
messy, hard to read code I've had to right as
a fix for this limitation.
>
> [ Rob: if you actually did not know of this new ability, which I suspect since
> it is
> not mentioned anywhere, please leave it that way. ]
>
4. Re: Secret new routine_id() feature. (Attn: Rob)
Andy Serpa wrote:
> I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> routine
> numbers for functions occuring below in the code or in files including after
> the current
> one (if the routine is global). This new ability is not in the release notes,
> and
> the docs for routine_id() still say the routine must be "visible" to get the
> routine
> number.
>
> I assume this stems from the fact that all the code is now parsed in advance.
> While
> this is a welcome change, it begs the question: why not now allow full forward
> referencing
> and let us call routines defined below in the code directly?
>
> [ Rob: if you actually did not know of this new ability, which I suspect since
> it is
> not mentioned anywhere, please leave it that way. ]
Thanks for reporting this bug.
It will be fixed in the beta release.
It looks like only the interpreters (PD and RDS) have the bug.
Translated code, bound code, and shrouded code seem to work correctly.
Even in 2.4 and earlier, many programs were parsed completely,
or almost completely, before routine_id() was executed.
I think it's better from a language design point of view that
routine_id() looks only at earlier routines, not later.
My reasons are:
1. I like to torture people.
2. Check the EUforum archive for the other reasons.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Secret new routine_id() feature. (Attn: Rob)
Robert Craig wrote:
>
> Andy Serpa wrote:
> > I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> > routine
> > numbers for functions occuring below in the code or in files including after
> > the current
> > one (if the routine is global). This new ability is not in the release
> > notes, and
> > the docs for routine_id() still say the routine must be "visible" to get the
> > routine
> > number.
> >
> > I assume this stems from the fact that all the code is now parsed in
> > advance. While
> > this is a welcome change, it begs the question: why not now allow full
> > forward referencing
> > and let us call routines defined below in the code directly?
> >
> > [ Rob: if you actually did not know of this new ability, which I suspect
> > since it is
> > not mentioned anywhere, please leave it that way. ]
>
> Thanks for reporting this bug.
ARRGGGHH! It is *not* a bug. It is an improvement. It can actually help
people write better code.
> It will be fixed in the beta release.
I believe you spelled the colloquial word for copulation incorrectly, it
is not spelled 'fixed' 
> It looks like only the interpreters (PD and RDS) have the bug.
What 'bug'? You have actually got it right, now.
> Translated code, bound code, and shrouded code seem to work correctly.
You need to fix these then so that they can be just as helpful as the
interpreter.
> Even in 2.4 and earlier, many programs were parsed completely,
> or almost completely, before routine_id() was executed.
> I think it's better from a language design point of view that
> routine_id() looks only at earlier routines, not later.
That's just one point of view. Other points of view are just as valid but
you prevent your customers from having the freedom of choice. You just
impose your view on us.
> My reasons are:
> 1. I like to torture people.
This I can now believe. I suspect you are not joking.
> 2. Check the EUforum archive for the other reasons.
There are no reasons - just opinions. Please justify why
the absence of forward referencing for routines is a good thing.
And there are other messages in EUForum for supporting other valid
points of view too.
I'm begging...please don't destroy this good thing. Please.
BTW, Robert, are you ignoring me? Messages and emails that I've sent to
you continue to go unanswered.
--
Derek Parnell
Melbourne, Australia
6. Re: Secret new routine_id() feature. (Attn: Rob)
On Wed, 08 Dec 2004 19:00:54 -0800, Robert Craig
<guest at rapideuphoria.com> wrote:
> Thanks for reporting this bug.
> It will be fixed in the beta release.
> It looks like only the interpreters (PD and RDS) have the bug.
> Translated code, bound code, and shrouded code seem to work correctly.
> Even in 2.4 and earlier, many programs were parsed completely,
> or almost completely, before routine_id() was executed.
> I think it's better from a language design point of view that
> routine_id() looks only at earlier routines, not later.
> My reasons are:
> 1. I like to torture people.
> 2. Check the EUforum archive for the other reasons.
Hah!
People can and will write hard-to-read code Rob, there's nothing you
or anyone can do to stop them. The 'elegance' you think comes from
arranging functions in order is nothing compared to a program that
doesn't need to resort to hacks in order to function, or even a
program that has its functions arranged in LOGICAL order, rather than
chronological.
Restricting forward-reference is seen as a limitation. It's ALWAYS
seen as a limitation. If a user runs into the 'no forward-reference'
problem, they don't go "gee, RDS is looking out for me best
interests", do they? NO! They say "Damn, why doesn't this stupid
language let me define my functions where I like?! What is it, C circa
1982?!"
Stop pretending you're the arbiter of good coding style, and you'll
improve the Euphoria language by it. Those who have a need to get
around the forward-reference problem you've *imposed* on the language
will thank you.
--
MrTrick
7. Re: Secret new routine_id() feature. (Attn: Rob)
Robert Craig wrote:
>
> Andy Serpa wrote:
> > I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> > routine
> > numbers for functions occuring below in the code or in files including after
> > the current
> > one (if the routine is global). This new ability is not in the release
> > notes, and
> > the docs for routine_id() still say the routine must be "visible" to get the
> > routine
> > number.
> >
> > I assume this stems from the fact that all the code is now parsed in
> > advance. While
> > this is a welcome change, it begs the question: why not now allow full
> > forward referencing
> > and let us call routines defined below in the code directly?
> >
> > [ Rob: if you actually did not know of this new ability, which I suspect
> > since it is
> > not mentioned anywhere, please leave it that way. ]
>
> Thanks for reporting this bug.
> It will be fixed in the beta release.
> It looks like only the interpreters (PD and RDS) have the bug.
> Translated code, bound code, and shrouded code seem to work correctly.
> Even in 2.4 and earlier, many programs were parsed completely,
> or almost completely, before routine_id() was executed.
> I think it's better from a language design point of view that
> routine_id() looks only at earlier routines, not later.
> My reasons are:
> 1. I like to torture people.
> 2. Check the EUforum archive for the other reasons.
>
Yeah, that's what I figured. But why do you hate us? What have we ever done to
you? At some point your ideas about what's good and what isn't go too far. Are
you just sitting there saying to yourself, "Somebody somewhere is going to write
code *I* don't approve of -- I must not let that happen." This is something that
is in place now (unintentionally, yes, but you can't argue it is hard to
achieve), and you're going to take special steps to BLOCK it! I've read your
reasons in the past and just reviewed them now -- they're pretty weak and only
have to do with coding style. Having to jump through a bunch of extra hoops just
to be able to discover a routine number and then pass it to the right place when
it is *ALREADY AVAILABLE* for us is outrageous. This lifts a MAJOR burden with
some types of programs. I'm surprised you haven't forced a certain style of
indentation on us.
8. Re: Secret new routine_id() feature. (Attn: Rob)
Poll Question: Should routine_id() find find routines defined later?:
http://uboard.proboards32.com/index.cgi?board=general&action=display&num=1102561416
Robert Craig wrote:
>
> Andy Serpa wrote:
> > I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> > routine
> > numbers for functions occuring below in the code or in files including after
> > the current
> > one (if the routine is global). This new ability is not in the release
> > notes, and
> > the docs for routine_id() still say the routine must be "visible" to get the
> > routine
> > number.
> >
> > I assume this stems from the fact that all the code is now parsed in
> > advance. While
> > this is a welcome change, it begs the question: why not now allow full
> > forward referencing
> > and let us call routines defined below in the code directly?
> >
> > [ Rob: if you actually did not know of this new ability, which I suspect
> > since it is
> > not mentioned anywhere, please leave it that way. ]
>
> Thanks for reporting this bug.
> It will be fixed in the beta release.
> It looks like only the interpreters (PD and RDS) have the bug.
> Translated code, bound code, and shrouded code seem to work correctly.
> Even in 2.4 and earlier, many programs were parsed completely,
> or almost completely, before routine_id() was executed.
> I think it's better from a language design point of view that
> routine_id() looks only at earlier routines, not later.
> My reasons are:
> 1. I like to torture people.
> 2. Check the EUforum archive for the other reasons.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
9. Re: Secret new routine_id() feature. (Attn: Rob)
On Wed, 08 Dec 2004 19:48:13 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
>I'm surprised you haven't forced a certain style of indentation on us.
Oh, haven't you heard?, that'll be in 2.6.
--
MrTrick
10. Re: Secret new routine_id() feature. (Attn: Rob)
Patrick Barnes wrote:
>
> On Wed, 08 Dec 2004 19:48:13 -0800, Andy Serpa <guest at rapideuphoria.com>
> wrote:
> >I'm surprised you haven't forced a certain style of indentation on us.
> Oh, haven't you heard?, that'll be in 2.6.
Only the Dvorak keyboard will be supported in 2.8.
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
11. Re: Secret new routine_id() feature. (Attn: Rob)
On Wed, 08 Dec 2004 20:15:46 -0800, cklester <guest at rapideuphoria.com> wrote:
> > On Wed, 08 Dec 2004 19:48:13 -0800, Andy Serpa <guest at rapideuphoria.com>
> > wrote:
> > >I'm surprised you haven't forced a certain style of indentation on us.
> > Oh, haven't you heard?, that'll be in 2.6.
>
> Only the Dvorak keyboard will be supported in 2.8.
And in 3.0, the number of reserved words will be reduced to 2 - 'zero'
and 'one'.
--
MrTrick
12. Re: Secret new routine_id() feature. (Attn: Rob)
Patrick Barnes wrote:
>
> On Wed, 08 Dec 2004 19:00:54 -0800, Robert Craig
> <guest at rapideuphoria.com> wrote:
> > Thanks for reporting this bug.
> > It will be fixed in the beta release.
> > It looks like only the interpreters (PD and RDS) have the bug.
> > Translated code, bound code, and shrouded code seem to work correctly.
> > Even in 2.4 and earlier, many programs were parsed completely,
> > or almost completely, before routine_id() was executed.
> > I think it's better from a language design point of view that
> > routine_id() looks only at earlier routines, not later.
> > My reasons are:
> > 1. I like to torture people.
> > 2. Check the EUforum archive for the other reasons.
>
> Hah!
> People can and will write hard-to-read code Rob, there's nothing you
The code I've had to write to work around this problem
is far worse then routines out of order!
At least allow routine_id() to fing routines defined
later!!!!! PLEASE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> or anyone can do to stop them. The 'elegance' you think comes from
> arranging functions in order is nothing compared to a program that
> doesn't need to resort to hacks in order to function, or even a
> program that has its functions arranged in LOGICAL order, rather than
> chronological.
>
> Restricting forward-reference is seen as a limitation. It's ALWAYS
> seen as a limitation. If a user runs into the 'no forward-reference'
> problem, they don't go "gee, RDS is looking out for me best
> interests", do they? NO! They say "Damn, why doesn't this stupid
> language let me define my functions where I like?! What is it, C circa
> 1982?!"
>
> Stop pretending you're the arbiter of good coding style, and you'll
> improve the Euphoria language by it. Those who have a need to get
> around the forward-reference problem you've *imposed* on the language
> will thank you.
>
> --
> MrTrick
>
>
13. Re: Secret new routine_id() feature. (Attn: Rob)
Derek Parnell wrote:
> BTW, Robert, are you ignoring me? Messages and emails that I've sent to
> you continue to go unanswered.
I've received one e-mail from you regarding database.e.
I'll look at it tomorrow.
I had a busy day today. The front axle on my 89 Corolla
broke while I was driving on the highway. I had to get a
tow, and take public transit home. Fortunately the highway
was clogged with traffic, as usual, so it wasn't as dangerous as
it might sound.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
14. Re: Secret new routine_id() feature. (Attn: Rob)
Andy Serpa wrote:
> I'm surprised you haven't forced
> a certain style of indentation on us.
Only Python cares about indentation.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
15. Re: Secret new routine_id() feature. (Attn: Rob)
This is very interesting. Whether or not Rob decides to keep this
feature, er.. bug, I'll keep it in EG. Although, the reason you can
not call routines (by forward reference) directly is because the
parser does not see the routine as a defined symbol before it is
defined (obviously), where as routine_id() returns an id at run time.
This 'bug' also applies to variable_id() in EG, as well as
routine_name(), routine_list(), variable_name() and variable_list() as
well as read() and write().
~Greg
On Wed, 08 Dec 2004 16:25:43 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
>
> posted by: Andy Serpa <ac at onehorseshy.com>
>
> I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> routine numbers for functions occuring below in the code or in files including
> after the current one (if the routine is global). This new ability is not in the
> release notes, and the docs for routine_id() still say the routine must be
> "visible" to get the routine number.
>
> I assume this stems from the fact that all the code is now parsed in advance.
> While this is a welcome change, it begs the question: why not now allow full
> forward referencing and let us call routines defined below in the code directly?
>
> [ Rob: if you actually did not know of this new ability, which I suspect since
> it is not mentioned anywhere, please leave it that way. ]
>
>
>
>
16. Re: Secret new routine_id() feature. (Attn: Rob)
CoJaBo wrote:
>
> Patrick Barnes wrote:
> >
> > On Wed, 08 Dec 2004 19:00:54 -0800, Robert Craig
> > <guest at rapideuphoria.com> wrote:
> > > Thanks for reporting this bug.
> > > It will be fixed in the beta release.
> > > It looks like only the interpreters (PD and RDS) have the bug.
> > > Translated code, bound code, and shrouded code seem to work correctly.
> > > Even in 2.4 and earlier, many programs were parsed completely,
> > > or almost completely, before routine_id() was executed.
> > > I think it's better from a language design point of view that
> > > routine_id() looks only at earlier routines, not later.
> > > My reasons are:
> > > 1. I like to torture people.
> > > 2. Check the EUforum archive for the other reasons.
> >
> > Hah!
> > People can and will write hard-to-read code Rob, there's nothing you
> The code I've had to write to work around this problem
> is far worse then routines out of order!
> At least allow routine_id() to fing routines defined
> later!!!!! PLEASE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>
> > or anyone can do to stop them. The 'elegance' you think comes from
> > arranging functions in order is nothing compared to a program that
> > doesn't need to resort to hacks in order to function, or even a
> > program that has its functions arranged in LOGICAL order, rather than
> > chronological.
> >
> > Restricting forward-reference is seen as a limitation. It's ALWAYS
> > seen as a limitation. If a user runs into the 'no forward-reference'
> > problem, they don't go "gee, RDS is looking out for me best
> > interests", do they? NO! They say "Damn, why doesn't this stupid
> > language let me define my functions where I like?! What is it, C circa
> > 1982?!"
> >
> > Stop pretending you're the arbiter of good coding style, and you'll
> > improve the Euphoria language by it. Those who have a need to get
> > around the forward-reference problem you've *imposed* on the language
> > will thank you.
> >
> > --
> > MrTrick
> >
> >
I guess I will agree with everyone else in that routine_id() should be
able to return a unique integer id number at any section of code, instead
of just after defining the functions/procedures. I see nothing wrong
with being able to take advantage of fully parsed code at startup in this
case. and as it seems.. keeping this feature 'bug' would be in almost
everyones interest, I prosume?
17. Re: Secret new routine_id() feature. (Attn: Rob)
Robert Craig wrote:
>
> Thanks for reporting this bug.
> It will be fixed in the beta release.
> It looks like only the interpreters (PD and RDS) have the bug.
> Translated code, bound code, and shrouded code seem to work correctly.
> Even in 2.4 and earlier, many programs were parsed completely,
> or almost completely, before routine_id() was executed.
> I think it's better from a language design point of view that
> routine_id() looks only at earlier routines, not later.
> My reasons are:
> 1. I like to torture people.
> 2. Check the EUforum archive for the other reasons.
>
errr... if your reason really has to do with coding style then you must be
joking. If I'm looking for a routine passed to r_id(), I don't sit and
scan prior routines to find out what it does. I either utilize the find
feature of my editor or use findstr.
-- Brian
18. Re: Secret new routine_id() feature. (Attn: Rob)
Robert Craig wrote:
>
> Derek Parnell wrote:
> > BTW, Robert, are you ignoring me? Messages and emails that I've sent to
> > you continue to go unanswered.
>
> I've received one e-mail from you regarding database.e.
> I'll look at it tomorrow.
>
> I had a busy day today. The front axle on my 89 Corolla
> broke while I was driving on the highway. I had to get a
> tow, and take public transit home. Fortunately the highway
> was clogged with traffic, as usual, so it wasn't as dangerous as
> it might sound.
>
If you were more interesting in pleasing your customers you'd probably have a
much newer & nicer car...
19. Re: Secret new routine_id() feature. (Attn: Rob)
<rant><point-of-view type="Ricer">
Technically, the best Corolla ever made was the '85-'87
rear-wheel-drive coupe/hatchback, a.k.a. the 'AE-86'. They were small,
quick and easily turbocharged. They're very common in the
up-and-coming drifting scene. So newer isn't always 'nicer'. :)
</point-of-view></rant>
~Greg
On Wed, 08 Dec 2004 23:47:03 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
>
>
>
> posted by: Andy Serpa <ac at onehorseshy.com>
>
> Robert Craig wrote:
> >
> > Derek Parnell wrote:
> > > BTW, Robert, are you ignoring me? Messages and emails that I've sent to
> > > you continue to go unanswered.
> >
> > I've received one e-mail from you regarding database.e.
> > I'll look at it tomorrow.
> >
> > I had a busy day today. The front axle on my 89 Corolla
> > broke while I was driving on the highway. I had to get a
> > tow, and take public transit home. Fortunately the highway
> > was clogged with traffic, as usual, so it wasn't as dangerous as
> > it might sound.
> >
>
> If you were more interesting in pleasing your customers you'd probably have a
> much newer & nicer car...
>
>
>
>
>
20. Re: Secret new routine_id() feature. (Attn: Rob)
Vincent wrote:
>
> CoJaBo wrote:
> >
> > Patrick Barnes wrote:
> > >
> > > On Wed, 08 Dec 2004 19:00:54 -0800, Robert Craig
> > > <guest at rapideuphoria.com> wrote:
> > > > Thanks for reporting this bug.
> > > > It will be fixed in the beta release.
> > > > It looks like only the interpreters (PD and RDS) have the bug.
> > > > Translated code, bound code, and shrouded code seem to work correctly.
> > > > Even in 2.4 and earlier, many programs were parsed completely,
> > > > or almost completely, before routine_id() was executed.
> > > > I think it's better from a language design point of view that
> > > > routine_id() looks only at earlier routines, not later.
> > > > My reasons are:
> > > > 1. I like to torture people.
> > > > 2. Check the EUforum archive for the other reasons.
> > >
> > > Hah!
> > > People can and will write hard-to-read code Rob, there's nothing you
> > The code I've had to write to work around this problem
> > is far worse then routines out of order!
> > At least allow routine_id() to fing routines defined
> > later!!!!! PLEASE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> >
> >
> > > or anyone can do to stop them. The 'elegance' you think comes from
> > > arranging functions in order is nothing compared to a program that
> > > doesn't need to resort to hacks in order to function, or even a
> > > program that has its functions arranged in LOGICAL order, rather than
> > > chronological.
> > >
> > > Restricting forward-reference is seen as a limitation. It's ALWAYS
> > > seen as a limitation. If a user runs into the 'no forward-reference'
> > > problem, they don't go "gee, RDS is looking out for me best
> > > interests", do they? NO! They say "Damn, why doesn't this stupid
> > > language let me define my functions where I like?! What is it, C circa
> > > 1982?!"
> > >
> > > Stop pretending you're the arbiter of good coding style, and you'll
> > > improve the Euphoria language by it. Those who have a need to get
> > > around the forward-reference problem you've *imposed* on the language
> > > will thank you.
> > >
> > > --
> > > MrTrick
> > >
> > >
> I guess I will agree with everyone else in that routine_id() should be
> able to return a unique integer id number at any section of code, instead
> of just after defining the functions/procedures. I see nothing wrong
> with being able to take advantage of fully parsed code at startup in this
> case. and as it seems.. keeping this feature 'bug' would be in almost
> everyones interest, I prosume?
Just look at my poll:
Poll Question: Should routine_id() find find routines defined later?:
http://uboard.proboards32.com/index.cgi?board=general&action=display&num=1102561416
Robe
21. Re: Secret new routine_id() feature. (Attn: Rob)
On Wed, 08 Dec 2004 23:47:03 -0800, Andy Serpa <guest at rapideuphoria.com>
wrote:
> If you were more interesting in pleasing your customers you'd probably have a
> much newer & nicer car...
Hey! Don't knock mid to late 80's corollas!
--
MrTrick
22. Re: Secret new routine_id() feature. (Attn: Rob)
Robert Craig wrote:
>
> Andy Serpa wrote:
> > I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> > routine
> > numbers for functions occuring below in the code or in files including after
> > the current
> > one (if the routine is global). This new ability is not in the release
> > notes, and
> > the docs for routine_id() still say the routine must be "visible" to get the
> > routine
> > number.
> >
> > I assume this stems from the fact that all the code is now parsed in
> > advance. While
> > this is a welcome change, it begs the question: why not now allow full
> > forward referencing
> > and let us call routines defined below in the code directly?
> >
> > [ Rob: if you actually did not know of this new ability, which I suspect
> > since it is
> > not mentioned anywhere, please leave it that way. ]
>
> Thanks for reporting this bug.
> It will be fixed in the beta release.
> It looks like only the interpreters (PD and RDS) have the bug.
> Translated code, bound code, and shrouded code seem to work correctly.
> Even in 2.4 and earlier, many programs were parsed completely,
> or almost completely, before routine_id() was executed.
> I think it's better from a language design point of view that
> routine_id() looks only at earlier routines, not later.
> My reasons are:
> 1. I like to torture people.
> 2. Check the EUforum archive for the other reasons.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Hi
Just to add my voice to this debate - I'm with the keep this feature camp,
and its the binder and translator that should be fixed.
I have been very supportive of euphoria, and the way you have created it
and developed it, and you have done a good job. However I feel this is
kick in the teeth to your users, who have been crying out for developments
like this (even Derek is _STILL_ here!)
Lets look at the example of the Corrolla's wheel falling off. The wheel
fell off, and you can see an obvious design flaw, you take a great, and
simple, fix to the manufacturer, that would ensure that their drivers
can drive more safely, and that because of the safety feature, would
enhance the sales of the car. The manufacturer tells you that they won't
(not can't) fix it because thats the way they like it, and like torturing
their drivers, and shouldn't you be driving slower anyway (in a traffic
jam).
Would you buy a Corrolla again?
Euphoria is growing up - its time to let its users drive it forward, with you
at the helm, and you will be ensured new and repeat customers.
If you don't, you won't.
Chris
http://members.aol.com/chriscrylex/euphoria.htm
http://uboard.proboards32.com/
23. Re: Secret new routine_id() feature. (Attn: Rob)
Robert Craig wrote:
> Andy Serpa wrote:
> > I'm surprised you haven't forced
> > a certain style of indentation on us.
> Only Python cares about indentation.
And Derek Parnell. I should know. I was penalized for too much
indentation. :P
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
24. Re: Secret new routine_id() feature. (Attn: Rob)
> Andy Serpa wrote:
> >
> > I just noticed that in v2.5, routine_id() can now "see ahead" and give you
> > routine
> > numbers for functions occuring below in the code or in files including after
> > the current
> > one (if the routine is global). This new ability is not in the release
> > notes, and
> > the docs for routine_id() still say the routine must be "visible" to get the
> > routine
> > number.
> <snip>
Rob, i may not be a prolific coder -- and i'm just starting to do some of the
things i want to do in Euphoria -- but i know a ggod thing when i see it.
this "bug", as you call it, is something that is wanted/begged for/need by some
of the strongest coders and supporters of Euphoria on this EUForum. if you really
care about your customers, you'll keep this "bug" intact.
one thing i've noticed as i lurk on this EUForum, the new people are about
50-50, newbee programmers and experienced coders. changes like Derek and others
suggest and beg for are *necessary* for Euphoria to move forward. as Derek says,
"please!".
analytically,
--
jon
25. Re: Secret new routine_id() feature. (Attn: Rob)
Patrick Barnes wrote:
>
> On Wed, 08 Dec 2004 23:47:03 -0800, Andy Serpa <guest at rapideuphoria.com>
> wrote:
> > If you were more interesting in pleasing your customers you'd probably have
> > a much newer & nicer
> car...</font></i>
>
> Hey! Don't knock mid to late 80's corollas!
> --
> MrTrick
>
the BEST car i ever had was an '85 Nissan Sentra diesel.
up to 55 miles per gallon, 95mph if i had to, and easy to drive in any weather.
that is, until a big Texas pickup truck driver broadsided and killed my car.
i've got friends who buy, fix, and drive 1950's and 60's cars -- and Fort Worth
has a Model T Ford (1920's and 30's) club with dozens of cars.
a new car is an expensive, high insurance, and over-priced status symbol i'd
rather be without.
historically,
--
jon
26. Re: Secret new routine_id() feature. (Attn: Rob)
> Subject: Re: Secret new routine_id() feature. (Attn: Rob)
>
>
> posted by: cklester <cklester at yahoo.com>
>
> Robert Craig wrote:
>
>>> Andy Serpa wrote:
>>
>>>> > I'm surprised you haven't forced
>>>> > a certain style of indentation on us.
>>
>>> Only Python cares about indentation.
>
>
> And Derek Parnell. I should know. I was penalized for too much
> indentation. :P
>
> -=ck
The Eu interpreter allows such silly thing, as far as code clarity is
concerned, as:
if --because it's not certain
x=0 then --a ton of code here, on the same line so that it's more fun reading
--and printing
end --at least
--oh, did I mention this was an if block?
if
The arguments about code clarity given by RC just don't impress me. They just
don't stand against hard facts. I'm puzzled at how one can still use them
towards programmers, a bunch of them seasoned ones.
If you want to make your code clearer, you have to indent so that the text
placement is a visual clue as to where the blocks start and end. Why not use
this visual clue anyway in the interpreter?
Is a cascade of end if end while end for end if end if much clearer to read?
imho plainly not.
In this respect, Bach (using the with python directive) is quite more clever
than Eu, and has a lot of improvements over it.
CChris
27. Re: Secret new routine_id() feature. (Attn: Rob)
I will have to add my 2 cents in here, for what it matters.
I belive that forward refrencing with routine_id() would actually be
a improvement on a allready good system. True, that this may lead
to sloppy code, but the alternative to this, is allready proving that
sloppy code can be made, either way.
It's not the point, of weither or not, that you can create sloppy code,
everyone can create sloppy code. Intentionally, or not. I think the
design of the language has proven to be good. It's now the point, that
you have to face, of adding features that your user base would actually
want, in order to keep people with the language.
Otherwise, it will become stagnated just like every other language out
there. This is just like Assembly, C, C++, Java, and such langauges out
there. They got their systems made, proven that they can work, then they
had to hand the features development over to the programmers, to decide
on which should be implemented, and which shouldn't.
I also belive, that with the opening of the Euphoria Interpreter to PD,
that you will find more people showing valid ways in code, that features
can be implemented, while still keeping with the spirit of what Euphoria
is. People like what Euphoria is, they aren't going to disgrace it
further, to where it'll get away from the spirit of what it is.
Please Rob, listen to your users, both for yourself, and for what we have
to go through in order to make a program.
Mario
