1. EOF and GOTO and 0th array element
1. What is the equivalent to a BASIC EOF (end-of-file) marker that I can
test for?
My current solution for #1 - when inputing a list from a text file with:
object dd, f1
dd=get(f1)
At the end of the file, atom(dd) returns a zero, which I use to check
for an end-of-file marker. Is there a more "proper" way?
2. At the risk of incurring wrath for writing spaghetti code, is there a
GOTO equivalent?
3. in BASIC an array can be created with 0th (zeroth?) element in any
dimension, but I don't see how you can do that in a sequence. Can one
set up a Euphoric equivalent to such an element in a sequence?
4. Nested in a while...end while loop is a for..end for loop. If a
test fails in the for..end for loop I want to exit the while..end while
loop. However, using exit command in the for..end for loop seems to
only exit the "for" loop and does not apply to the "while" loop. Can
one indicate what to exit if using that command, or (as in the example
below) do I have to set some condition in the "for" loop to test outside
of it in order to exit the "while" loop?
.
.
somemarker=true
while 1 do
.
.
-- test values; if fail, exit loop
for y=1 to 10 do
if test y fails then
somemarker=false
exit
end if
end for
if somemarker=false then
exit
end if
.
.
end while
.
.
Again, many thanks for any help
darceman
2. Re: EOF and GOTO and 0th array element
On 22 Aug 2002, at 19:56, darceman wrote:
> 2. At the risk of incurring wrath for writing spaghetti code, is there a
> GOTO equivalent?
In Karl's Bach/Bliss, but not in Euphoria.
> 3. in BASIC an array can be created with 0th (zeroth?) element in any
> dimension, but I don't see how you can do that in a sequence. Can one
> set up a Euphoric equivalent to such an element in a sequence?
No, the first element is one. I once tried indexing my zero-eth finger, and got
lost. Only time i found this useful was in getting the string length, and Eu
doesn't do strings at all, only sequences. Which can be quite an advantage.
It would be nice if a out-of-range index would return "" tho.
> 4. Nested in a while...end while loop is a for..end for loop. If a
> test fails in the for..end for loop I want to exit the while..end while
> loop. However, using exit command in the for..end for loop seems to
> only exit the "for" loop and does not apply to the "while" loop. Can
> one indicate what to exit if using that command, or (as in the example
> below) do I have to set some condition in the "for" loop to test outside
> of it in order to exit the "while" loop?
No, for that, you need to use spagettti code, with extra vars to set and do
boolean tests on to see what to exit and when it's ok to continue to loop. Do
a lot of if-then blocking, and move the logical program flow out into other
functions and procedures, and deal with the fallout of var scopes. Moving
code out into other functions makes recursion really difficult, but since we
cannot goto the EndOf_Whatever loop, or any other goto :target: like in
Bach/Bliss or basic, basic-to-Euphoria translators cannot handle the simple
elegant "goto".
Kat
3. Re: EOF and GOTO and 0th array element
----- Original Message -----
From: "darceman" <darce at ffi.com>
To: "EUforum" <EUforum at topica.com>
Subject: EOF and GOTO and 0th array element
>
> 1. What is the equivalent to a BASIC EOF (end-of-file) marker that I can
> test for?
>
> My current solution for #1 - when inputing a list from a text file with:
>
> object dd, f1
>
> dd=get(f1)
>
> At the end of the file, atom(dd) returns a zero, which I use to check
> for an end-of-file marker. Is there a more "proper" way?
That is the proper way in Euphoria.
>
> 2. At the risk of incurring wrath for writing spaghetti code, is there a
> GOTO equivalent?
Yes and no. Strictly speaking there is no GOTO (thankfully). However, if you
wish to write hard-to-read and hard-to-maintain code, Euphoria still allows
this option. GOTO can be emulated using a state machine concept.
function routine_1()
-- do some work
return 2
end function
function routine_2()
-- do some work
if xyz then
return 3
else
return 2
end if
end function
function routine_3()
-- do some work
if abc then
return 2
else
return 1
end if
end function
function routine_4()
-- do some work
if qwerty then
return 4
else
if ytrewq then
return 1
end if
-- do more work
if ytrewq then
return 3
else
return 0
end if
end if
end function
-- State Machine --
x = 0
state = 1
while x != -1 do
x = routine_id(sprintf("routine_%d", state))
if x != -1 then
state = call_func(x,{})
end if
end while
> 3. in BASIC an array can be created with 0th (zeroth?) element in any
> dimension, but I don't see how you can do that in a sequence. Can one
> set up a Euphoric equivalent to such an element in a sequence?
No. Euphoria uses a 1-based index philosophy. The first element in a series
is always 1.
Oh, except for routine_id().
Oh, and open() as well.
> 4. Nested in a while...end while loop is a for..end for loop. If a
> test fails in the for..end for loop I want to exit the while..end while
> loop. However, using exit command in the for..end for loop seems to
> only exit the "for" loop and does not apply to the "while" loop. Can
> one indicate what to exit if using that command, or (as in the example
> below) do I have to set some condition in the "for" loop to test outside
> of it in order to exit the "while" loop?
>
> .
> .
> somemarker=true
> while 1 do
> .
> .
> -- test values; if fail, exit loop
> for y=1 to 10 do
> if test y fails then
> somemarker=false
> exit
> end if
> end for
> if somemarker=false then
> exit
> end if
> .
> .
> end while
> .
> .
>
This request just keeps on coming up. Euphoria doesn't make it easy for us.
It encourages hard-to-read code in this instance. My "pet" solution is a
form of controlled GOTO.
somemarker: while 1 do
.
.
-- test values; if fail, exit loop
for y=1 to 10 do
if test y fails then
exit somemarker
end if
end for
.
.
end while
----------------
cheers,
Derek Parnell
4. Re: EOF and GOTO and 0th array element
On 0, Derek Parnell <ddparnell at bigpond.com> wrote:
>
> > 3. in BASIC an array can be created with 0th (zeroth?) element in any
> > dimension, but I don't see how you can do that in a sequence. Can one
> > set up a Euphoric equivalent to such an element in a sequence?
>
> No. Euphoria uses a 1-based index philosophy. The first element in a series
> is always 1.
>
> Oh, except for routine_id().
Yes, routine_id() starts at 0.
>
> Oh, and open() as well.
open() starts at 3, I think. (0, 1, and 2 are stdin, stdout, and
stderr,
although the situation is slightly different with Linux due to ncurses.
(ncurses seems to like to redirect stdout to stderr on occasion, I'm
not sure
why, among other things.))
jbrown
--
Please don't use http://fastmail.fm
(I like feeling special.)
5. Re: EOF and GOTO and 0th array element
On 0, darceman <darce at ffi.com> wrote:
>
> 1. What is the equivalent to a BASIC EOF (end-of-file) marker that I can
> test for?
>
> My current solution for #1 - when inputing a list from a text file with:
>
> object dd, f1
>
> dd=get(f1)
>
> At the end of the file, atom(dd) returns a zero, which I use to check
> for an end-of-file marker. Is there a more "proper" way?
>
This seems like the proper way, however get() always returns a 2
element sequence which is either a successful translation of an
euphorian
object from a file or a failure code.
You probably mean this:
dd=getc(f1) --get one character at a time
if dd=-1 then
--EOF
end if
or this:
dd=gets(f1) --get one line at a time
if atom(dd)=1 then
--EOF
end if
>
> 2. At the risk of incurring wrath for writing spaghetti code, is there a
> GOTO equivalent?
>
Not in pure Eu. You could emulate it with state variables, or try
Bach/Bliss.
Also, I wrote a parser which emulated goto statements with recursive
function calls, but this meant that you could only use goto inside of
routines (I think Bliss had this restriction as well).
> 3. in BASIC an array can be created with 0th (zeroth?) element in any
> dimension, but I don't see how you can do that in a sequence. Can one
> set up a Euphoric equivalent to such an element in a sequence?
>
Sequences start at 1.
> 4. Nested in a while...end while loop is a for..end for loop. If a
> test fails in the for..end for loop I want to exit the while..end while
> loop. However, using exit command in the for..end for loop seems to
> only exit the "for" loop and does not apply to the "while" loop. Can
> one indicate what to exit if using that command, or (as in the example
> below) do I have to set some condition in the "for" loop to test outside
> of it in order to exit the "while" loop?
>
> .
> .
> somemarker=true
> while 1 do
> .
> .
> -- test values; if fail, exit loop
> for y=1 to 10 do
> if test y fails then
> somemarker=false
> exit
> end if
> end for
> if somemarker=false then
> exit
> end if
> .
> .
> end while
> .
> .
>
Your example looks right. There is no way to exit the while loop
directly
from the for loop. I might extend rparse to emulate this though, if I
can find the time.
> Again, many thanks for any help
>
> darceman
>
jbrown
--
http://fastmail.fm - Email service worth paying for. Try it for free.
6. Re: EOF and GOTO and 0th array element
Derek <ddparnell at bigpond.com> wrote:
<snip>
>> 2. At the risk of incurring wrath for writing spaghetti code, is there a
>> GOTO equivalent?
> Yes and no. Strictly speaking there is no GOTO (thankfully).
I'm thankful for this, too.
<snip>
>> 4. Nested in a while...end while loop is a for..end for loop. If a
>> test fails in the for..end for loop I want to exit the while..end while
>> loop. However, using exit command in the for..end for loop seems to
>> only exit the "for" loop and does not apply to the "while" loop. Can
>> one indicate what to exit if using that command, or (as in the example
>> below) do I have to set some condition in the "for" loop to test outside
>> of it in order to exit the "while" loop?
>>
>> .
>> .
>> somemarker=true
>> while 1 do
>> .
>> .
>> -- test values; if fail, exit loop
>> for y=1 to 10 do
>> if test y fails then
>> somemarker=false
>> exit
>> end if
>> end for
>> if somemarker=false then
>> exit
>> end if
>> .
>> .
>> end while
>> .
>> .
>>
> This request just keeps on coming up. Euphoria doesn't make it easy for us.
> It encourages hard-to-read code in this instance. My "pet" solution is a
> form of controlled GOTO.
> somemarker: while 1 do
> .
> .
> -- test values; if fail, exit loop
> for y=1 to 10 do
> if test y fails then
> exit somemarker
> end if
> end for
> .
> .
> end while
For handling such situations more elegant, I'd like to have an enhanced
exit-statement in Euphoria, where the numbers of levels to exit can be
given. Then this code snippet would be as simple as:
----------------------------------------
while 1 do
.
.
-- test values; if fail, exit loop
for y=1 to 10 do
if test y fails then
exit 2 -- exits both the for loop and the while loop
end if
end for
.
.
end while
----------------------------------------
For instance, PowerBASIC has a similar feature (One has to write
"exit,exit" instead of "exit 2".) With this very simple and powerful
feature, the last argument for GOTO will disappear! 
<quote>
Many authors have suggested language features [...]
which are expressed in terms of *exit*, *jump-out*,
*break*, or *leave* statements. Kosaraju [57] has
proved that such statements are sufficient to
express all programs without *go to*'s and without
any extra computation, but only if an exit from
arbitrarily many levels of control is permitted.
<unquote>
[Knuth, Donald E.: Structured Programming with go to Statements.
Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
> ----------------
> cheers,
> Derek Parnell
Regards,
Juergen
7. Re: EOF and GOTO and 0th array element
----- Original Message -----
From: "Juergen Luethje" <jluethje at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: EOF and GOTO and 0th array element
>
> For handling such situations more elegant, I'd like to have an enhanced
> exit-statement in Euphoria, where the numbers of levels to exit can be
> given. Then this code snippet would be as simple as:
>
> ----------------------------------------
> while 1 do
> .
> .
> -- test values; if fail, exit loop
> for y=1 to 10 do
> if test y fails then
> exit 2 -- exits both the for loop and the while loop
> end if
> end for
> .
> .
> end while
> ----------------------------------------
>
> For instance, PowerBASIC has a similar feature (One has to write
> "exit,exit" instead of "exit 2".) With this very simple and powerful
> feature, the last argument for GOTO will disappear!
I will argue against the "exit n" idea for a number of reasons.
The first reason is that over time, the value of 'n' might change as
modifications change the nesting level of the 'exit' statement. This means
that one would have to examine, and possibly update, all the 'exit n'
statements whenever you add or remove a loop block. Instead of 'exit n', I
would suggest that 'exit name' is a safer and less maintenance intensive
alternative. The reason being that the name (which can only be attached to
the start of a loop block), does not change when one adds and deletes loop
blocks. Thus any reference to the name does not have to be examined. Another
reason I prefer this is that a descriptive name can aid the reader as to
what the code is trying to do, whereas a number doesn't do this.
So in summary, I propose that the syntax for 'while' and 'for' loop blocks
be changed to ...
[<NAME>:]while <BOOLEANEXPR> do <STATEMENTS> end while
[<NAME>:]for <FORCONTROL> do <STATEMENTS> end for
and the <STATEMENTS> may include one or more ...
exit [<NAME>]
where if no name is specified, the loop block that the exit is in is
terminated. If a name is specified, the named loop block is terminated. If
there is no loop block thus named, an error is generated.
I refer to this idea as a controlled GOTO. Firstly, it must be mentioned
that the existing 'exit' statement is also a controlled GOTO. It passes
control to the end of a loop block. It is controlled in the sense that the
target of the exit is not any arbitary line of code. It is ALWAYS the first
line after the loop block. My proposal is no different in concept. Control
is always passed to the first line of code after the named loop block.
Another reason for preferring this style is based on clarity of expression.
If fairly sure that if a programmer codes 'exit 2' it is NOT because she
wishes to exit the loop block that just happens to enclose the current one.
I suspect the the coder actually wishes to exit a specific loop block. If
that is the case, naming the loop block that is of interest helps clarify
the code.
This proposal would not break any existing Euphoria code.
Example:
TextLine = gets(theFile)
ProcessFile: while not atom(TextLine) do
epos = find('=', TextLine)
if epos != 0 then
theKey = trim(TextLine[1..epos-1])
theValue = trim(TextLine[epos+1..length(TextLine)]
for i = 1 to length(theValue) do
if theValue[i] = ',' then
if i = length(theValue) or
theValue[i+1] = ' ' then
ErrMsg("Subvalue is invalid")
exit ProcessFile
end if
end if
end for
ProcessCmd(theKey, theValue)
end if
TextLne = gets(theFile)
end while
close(theFile)
> <quote>
> Many authors have suggested language features [...]
> which are expressed in terms of *exit*, *jump-out*,
> *break*, or *leave* statements. Kosaraju [57] has
> proved that such statements are sufficient to
> express all programs without *go to*'s and without
> any extra computation, but only if an exit from
> arbitrarily many levels of control is permitted.
> <unquote>
> [Knuth, Donald E.: Structured Programming with go to Statements.
> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
Hey, if the Master says so, its okay by me too! :) Notice though that the
idea of "arbitrarily many levels of control" is not necessarily expressed in
terms of Number of Levels.
----------------
cheers,
Derek Parnell
8. Re: EOF and GOTO and 0th array element
On 23 Aug 2002, at 10:43, Juergen Luethje wrote:
>
> Derek <ddparnell at bigpond.com> wrote:
>
> <snip>
> >> 2. At the risk of incurring wrath for writing spaghetti code, is there a
> >> GOTO
> >> equivalent?
>
> > Yes and no. Strictly speaking there is no GOTO (thankfully).
>
> I'm thankful for this, too.
>
> <snip>
> >> 4. Nested in a while...end while loop is a for..end for loop. If a
> >> test fails in the for..end for loop I want to exit the while..end while
> >> loop. However, using exit command in the for..end for loop seems to
> >> only exit the "for" loop and does not apply to the "while" loop. Can
> >> one indicate what to exit if using that command, or (as in the example
> >> below) do I have to set some condition in the "for" loop to test outside of
> >> it in order to exit the "while" loop?
> >>
> >> .
> >> .
> >> somemarker=true
> >> while 1 do
> >> .
> >> .
> >> -- test values; if fail, exit loop
> >> for y=1 to 10 do
> >> if test y fails then
> >> somemarker=false
> >> exit
> >> end if
> >> end for
> >> if somemarker=false then
> >> exit
> >> end if
> >> .
> >> .
> >> end while
> >> .
> >> .
> >>
>
> > This request just keeps on coming up. Euphoria doesn't make it easy for us.
> > It
> > encourages hard-to-read code in this instance. My "pet" solution is a form
> > of
> > controlled GOTO.
>
>
> > somemarker: while 1 do
> > .
> > .
> > -- test values; if fail, exit loop
> > for y=1 to 10 do
> > if test y fails then
> > exit somemarker
> > end if
> > end for
> > .
> > .
> > end while
>
>
> For handling such situations more elegant, I'd like to have an enhanced
> exit-statement in Euphoria, where the numbers of levels to exit can be
> given. Then this code snippet would be as simple as:
>
> ----------------------------------------
> while 1 do
> .
> .
> -- test values; if fail, exit loop
> for y=1 to 10 do
> if test y fails then
> exit 2 -- exits both the for loop and the while loop
> end if
> end for
> .
> .
> end while
> ----------------------------------------
>
> For instance, PowerBASIC has a similar feature (One has to write
> "exit,exit" instead of "exit 2".) With this very simple and powerful
> feature, the last argument for GOTO will disappear!
Nope. As Derik said in his last post, the "end while" is a tag for the "exit" to
"goto",, it is a controlled "goto", and an *extremely* controlled one. I would
prefer a goto to goto whatever label i specify.
What if you code using "exit" or "exit2", and then, in your rapid development
system, you you bracket those loops with another? go thu and change all
the exitx lines? sheesh. Drop in goto and you need to change nothing. I don't
believe the interpreter need to be cobbled by an assortment of exit
statements, resumes, leave, break, jump, or loop labels, when one goto and
one label for it will take care of this recurring thread.
Kat
9. Re: EOF and GOTO and 0th array element
Hello Derek,
Derek <ddparnell at bigpond.com> wrote:
<snip>
> I will argue against the "exit n" idea for a number of reasons.
>
> The first reason is that over time, the value of 'n' might change as
> modifications change the nesting level of the 'exit' statement. This means
> that one would have to examine, and possibly update, all the 'exit n'
> statements whenever you add or remove a loop block. Instead of 'exit n', I
> would suggest that 'exit name' is a safer and less maintenance intensive
> alternative. The reason being that the name (which can only be attached to
> the start of a loop block), does not change when one adds and deletes loop
> blocks. Thus any reference to the name does not have to be examined. Another
> reason I prefer this is that a descriptive name can aid the reader as to
> what the code is trying to do, whereas a number doesn't do this.
>
> So in summary, I propose that the syntax for 'while' and 'for' loop blocks
> be changed to ...
> [<NAME>:]while <BOOLEANEXPR> do <STATEMENTS> end while
> [<NAME>:]for <FORCONTROL> do <STATEMENTS> end for
> and the <STATEMENTS> may include one or more ...
> exit [<NAME>]
> where if no name is specified, the loop block that the exit is in is
> terminated. If a name is specified, the named loop block is terminated. If
> there is no loop block thus named, an error is generated.
Now, having read your explanations, and having thought about the problem
more in depth, I'm convinced that your proposal for enhancement of the
exit statement is really better than "exit n".
> I refer to this idea as a controlled GOTO. Firstly, it must be mentioned
> that the existing 'exit' statement is also a controlled GOTO. It passes
> control to the end of a loop block. It is controlled in the sense that the
> target of the exit is not any arbitary line of code. It is ALWAYS the first
> line after the loop block. My proposal is no different in concept. Control
> is always passed to the first line of code after the named loop block.
Well, in this sense, even an "if/end if" statement could be called kind
of "goto". That's not what I meant. My previous remarks about GOTO were
only meant to refer to the explicit GOTO statement, that is provided by
BASIC and other languages, and that obviously some people would like to
see in Euphoria.
<snipped in agreement>
>> <quote>
>> Many authors have suggested language features [...]
>> which are expressed in terms of *exit*, *jump-out*,
>> *break*, or *leave* statements. Kosaraju [57] has
>> proved that such statements are sufficient to
>> express all programs without *go to*'s and without
>> any extra computation, but only if an exit from
>> arbitrarily many levels of control is permitted.
>> <unquote>
>> [Knuth, Donald E.: Structured Programming with go to Statements.
>> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
> Hey, if the Master says so, its okay by me too! :) Notice though that the
> idea of "arbitrarily many levels of control" is not necessarily expressed in
> terms of Number of Levels.
I wrote this quote as an argument against the GOTO statement (in the
sense I explained above), not as an argument against your "enhanced exit"
proposal.
> ----------------
> cheers,
> Derek Parnell
Thank you for your comprehensive reply.
Regards,
Juergen
10. Re: EOF and GOTO and 0th array element
On 0, Juergen Luethje <jluethje at gmx.de> wrote:
>
> Hello Derek,
>
> Derek <ddparnell at bigpond.com> wrote:
>
> <snip>
> > I will argue against the "exit n" idea for a number of reasons.
> >
> > The first reason is that over time, the value of 'n' might change as
> > modifications change the nesting level of the 'exit' statement. This means
> > that one would have to examine, and possibly update, all the 'exit n'
> > statements whenever you add or remove a loop block. Instead of 'exit n', I
> > would suggest that 'exit name' is a safer and less maintenance intensive
> > alternative. The reason being that the name (which can only be attached to
> > the start of a loop block), does not change when one adds and deletes loop
> > blocks. Thus any reference to the name does not have to be examined. Another
> > reason I prefer this is that a descriptive name can aid the reader as to
> > what the code is trying to do, whereas a number doesn't do this.
> >
> > So in summary, I propose that the syntax for 'while' and 'for' loop blocks
> > be changed to ...
>
> > [<NAME>:]while <BOOLEANEXPR> do <STATEMENTS> end while
> > [<NAME>:]for <FORCONTROL> do <STATEMENTS> end for
>
> > and the <STATEMENTS> may include one or more ...
> > exit [<NAME>]
> > where if no name is specified, the loop block that the exit is in is
> > terminated. If a name is specified, the named loop block is terminated. If
> > there is no loop block thus named, an error is generated.
>
> Now, having read your explanations, and having thought about the problem
> more in depth, I'm convinced that your proposal for enhancement of the
> exit statement is really better than "exit n".
>
Goto could be used for the same purpose.
> > I refer to this idea as a controlled GOTO. Firstly, it must be mentioned
> > that the existing 'exit' statement is also a controlled GOTO. It passes
> > control to the end of a loop block. It is controlled in the sense that the
> > target of the exit is not any arbitary line of code. It is ALWAYS the first
> > line after the loop block. My proposal is no different in concept. Control
> > is always passed to the first line of code after the named loop block.
>
> Well, in this sense, even an "if/end if" statement could be called kind
> of "goto". That's not what I meant. My previous remarks about GOTO were
> only meant to refer to the explicit GOTO statement, that is provided by
> BASIC and other languages, and that obviously some people would like to
> see in Euphoria.
>
> <snipped in agreement>
Such as I. With goto, exit/continue/exit(n)/next(n) would not be
needed.
Of course, with goto, for..end for/while..end while/if..end
if/select..end select
or even procedure..end procedure/function..end function wouldn't be
needed
either. My proposal: implement goto and goto-alternatives, and then let
the community decided which style is best by seeing which one is used
more often.
>
> >> <quote>
> >> Many authors have suggested language features [...]
> >> which are expressed in terms of *exit*, *jump-out*,
> >> *break*, or *leave* statements. Kosaraju [57] has
> >> proved that such statements are sufficient to
> >> express all programs without *go to*'s and without
> >> any extra computation, but only if an exit from
> >> arbitrarily many levels of control is permitted.
> >> <unquote>
> >> [Knuth, Donald E.: Structured Programming with go to Statements.
> >> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
>
> > Hey, if the Master says so, its okay by me too! :) Notice though that the
> > idea of "arbitrarily many levels of control" is not necessarily expressed in
> > terms of Number of Levels.
>
> I wrote this quote as an argument against the GOTO statement (in the
> sense I explained above), not as an argument against your "enhanced exit"
> proposal.
>
If used in a limited fashion, goto works fine with easily-readable
code.
(i.e. used only to exit loops (entering would be too tricky) and not to
replace
loops or if/switch statements or routines or any of the stuff which
should be
seperated to be made more readable.)
> > ----------------
> > cheers,
> > Derek Parnell
>
> Thank you for your comprehensive reply.
>
> Regards,
> Juergen
>
I think that all features should be implemeted, and that the programmer
should
choose one's own style from there. (Of course Rob would never agree to
that,
and I am better at Euphoria than I am with C, so I continue to write
preproc
to get around this limitation. And yes, writing a preproc to implement
the
goto statement is possible (which I did with rparse, and David Cuny did
with ebasic), although the converted code is so messy it is a terrible
idea.)
jbrown
--
11. Re: EOF and GOTO and 0th array element
jbrown105 <jbrown105 at speedymail.org> wrote:
> On 0, Juergen Luethje <jluethje at gmx.de> wrote:
>>
>> Hello Derek,
>>
>> Derek <ddparnell at bigpond.com> wrote:
[Derek's proposal for enhancement of the exit statement]
> Goto could be used for the same purpose.
Technically speaking, this is correct of course. But that's not an
argument for the use of GOTO. Not anything that could be done, also
should be done. GOTO isn't necessary at all.
<snip>
>> the explicit GOTO statement, that is provided by BASIC and other
>> languages, and that obviously some people would like to see in
>> Euphoria.
> Such as I. With goto, exit/continue/exit(n)/next(n) would not be
> needed.
> Of course, with goto, for..end for/while..end while/if..end
> if/select..end select or even procedure..end procedure/function..end
> function wouldn't be needed either.
Right, but there has been good reasons why Rob nevertheless decided to
implement while..end while etc. in Euphoria.
Arguing this way, I also could say Euphoria would not be needed at all,
because programs can be written in assembler.
The bottom line is, that GOTO is a low level statement, for which there
is no place in a high level language like Euphoria. High level languages
should encourage structured programming and structured thinking.
GOTO doesn't do that. GOTO isn't necessary in a high level language such
as Euphoria, but GOTO has the potential to produce "logical spaghetti",
which will lead to less readable and less maintainable code.
If I want to do low level coding, I'll do it in assembler -- it is much
fun for me, I don't know a better low level language, and I can do as
much conditional and unconditional jumps as I like. 
But I like
Euphoria, because it is a high level language. And I would like it to
remain a high level language.
> My proposal: implement goto and goto-alternatives, and then let
> the community decided which style is best by seeing which one is used
> more often.
"best" and "most often" aren't synonyms, unfortunately things are more
complicated ...
There are fairly enough other languages that provide GOTO. Why not keep
at least one high level language clean?
>>>> <quote>
>>>> Many authors have suggested language features [...]
>>>> which are expressed in terms of *exit*, *jump-out*,
>>>> *break*, or *leave* statements. Kosaraju [57] has
>>>> proved that such statements are sufficient to
>>>> express all programs without *go to*'s and without
>>>> any extra computation, but only if an exit from
>>>> arbitrarily many levels of control is permitted.
>>>> <unquote>
>>>> [Knuth, Donald E.: Structured Programming with go to Statements.
>>>> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
<snip>
> If used in a limited fashion, goto works fine with easily-readable
> code.
This is often said in this context. The decisive word is *if* ...
After (not only) my experience, this is just a theoretical consideration.
In practice, GOTO is *not* used in a limited fashion in (far too) many
programs. I say this after having read *megabytes* of BASIC source code.
> (i.e. used only to exit loops (entering would be too tricky)
In a high level programming language, *structured* statements should be
used for that purpose.
<quote>
What we really want is to conceive of our program in
such a way that we rarely even /think/ about *go to*
statements, because the real need for them hardly ever
arises. The language in which we express our ideas has
a strong influence on our thought processes. Therefore,
Dijkstra [23] asks for more new language features --
structures which encourage clear thinking -- in order
to avoid the *go to*'s temptations toward complications.
<unquote>
[Knuth, Donald E.: Structured Programming with go to Statements.
Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
This was written in the 70's of the last century. Now we have modern
languages such as Euphoria.
And now, in our beloved elegant high level modern programming
language, which encourages structured programming, you want to
introduce this unstructured low level statement GOTO.
I simply cannot understand why. There is no need for it.
(Well, maybe so long as there is no enhancement of Euphoria's exit
statement, there will be a little need. But the consequence should be
to enhance the exit statement, not to introduce GOTO.)
> and not to replace loops or if/switch statements or routines or any of
> the stuff which should be seperated to be made more readable.)
<snip>
> I think that all features should be implemeted,
I disagree. Anything that is not necessary one the one hand, and has
the potential to cause harm one the other hand, should *not* be
implemented.
> and that the programmer
> should choose one's own style from there. (Of course Rob would never
> agree to that, and I am better at Euphoria than I am with C, so I continue
> to write preproc to get around this limitation.
Well, if you consider the lack of GOTO as a limitation, I can understand
you, of course. For me this is not a limitation. I've been programming
in PowerBASIC for about 10 years, there is GOTO of course.
I simply never needed it.
> And yes, writing a preproc to implement the goto statement is possible
> (which I did with rparse, and David Cuny did with ebasic), although the
> converted code is so messy it is a terrible idea.)
> jbrown
Just my 2 Euro cents.
Best regards,
Juergen
12. Re: EOF and GOTO and 0th array element
On 24 Aug 2002, at 11:41, Juergen Luethje wrote:
>
> jbrown105 <jbrown105 at speedymail.org> wrote:
>
> > On 0, Juergen Luethje <jluethje at gmx.de> wrote:
> >>
> >> Hello Derek,
> >>
> >> Derek <ddparnell at bigpond.com> wrote:
>
> [Derek's proposal for enhancement of the exit statement]
>
> > Goto could be used for the same purpose.
>
> Technically speaking, this is correct of course. But that's not an
> argument for the use of GOTO. Not anything that could be done, also
> should be done. GOTO isn't necessary at all.
But yet the assy code under Eu is full of them.
> <snip>
>
> >> the explicit GOTO statement, that is provided by BASIC and other
> >> languages, and that obviously some people would like to see in
> >> Euphoria.
>
> > Such as I. With goto, exit/continue/exit(n)/next(n) would not be
> > needed.
> > Of course, with goto, for..end for/while..end while/if..end
> > if/select..end select or even procedure..end procedure/function..end
> > function wouldn't be needed either.
>
> Right, but there has been good reasons why Rob nevertheless decided to
> implement while..end while etc. in Euphoria.
> Arguing this way, I also could say Euphoria would not be needed at all,
> because programs can be written in assembler.
>
> The bottom line is, that GOTO is a low level statement, for which there
> is no place in a high level language like Euphoria. High level languages
> should encourage structured programming and structured thinking.
Define "structured". You mean it looks nice when printed out in your text
editor, right? Or in blocks of code *you* understand, regardless of how
anyone else processes the code in their head? Or how you see the flow of
the thread, with lots of boolean tests to interrupt getting from point A to
point
B?
> GOTO doesn't do that. GOTO isn't necessary in a high level language such
> as Euphoria, but GOTO has the potential to produce "logical spaghetti",
> which will lead to less readable and less maintainable code.
And hammers can be used as weapons, and so we should outlaw hammers.
Potato chips can choke presidents of the usa named Bush, so we should
outlaw them too,,, on 2nd thought..err,, nevermind.
> If I want to do low level coding, I'll do it in assembler -- it is much
> fun for me, I don't know a better low level language, and I can do as
> much conditional and unconditional jumps as I like. But I like
> Euphoria, because it is a high level language. And I would like it to
> remain a high level language.
>
> > My proposal: implement goto and goto-alternatives, and then let
> > the community decided which style is best by seeing which one is used
> > more often.
>
> "best" and "most often" aren't synonyms, unfortunately things are more
> complicated ...
I agree. Look at all the fuss over using one simple word like goto. It can be
the least used keyword, but still the best in certain situations.
> There are fairly enough other languages that provide GOTO. Why not keep
> at least one high level language clean?
>
> >>>> <quote>
> >>>> Many authors have suggested language features [...]
> >>>> which are expressed in terms of *exit*, *jump-out*,
> >>>> *break*, or *leave* statements. Kosaraju [57] has
> >>>> proved that such statements are sufficient to
> >>>> express all programs without *go to*'s and without
> >>>> any extra computation, but only if an exit from
> >>>> arbitrarily many levels of control is permitted.
> >>>> <unquote>
> >>>> [Knuth, Donald E.: Structured Programming with go to Statements.
> >>>> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
>
> <snip>
>
> > If used in a limited fashion, goto works fine with easily-readable
> > code.
>
> This is often said in this context. The decisive word is *if* ...
> After (not only) my experience, this is just a theoretical consideration.
> In practice, GOTO is *not* used in a limited fashion in (far too) many
> programs. I say this after having read *megabytes* of BASIC source code.
And lots of people use pliers as an 8oz hammer, when they don't have an
8oz hammer. Most people use a worn screwdriver as a chisel. Some people
even use a light bulb as a heat source: heat lamp. But what they do doesn't
bother me, that's their private world.
> > (i.e. used only to exit loops (entering would be too tricky)
>
> In a high level programming language, *structured* statements should be
> used for that purpose.
>
> <quote>
> What we really want is to conceive of our program in
> such a way that we rarely even /think/ about *go to*
> statements, because the real need for them hardly ever
> arises. The language in which we express our ideas has
> a strong influence on our thought processes. Therefore,
> Dijkstra [23] asks for more new language features --
> structures which encourage clear thinking -- in order
> to avoid the *go to*'s temptations toward complications.
> <unquote>
> [Knuth, Donald E.: Structured Programming with go to Statements.
> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
>
> This was written in the 70's of the last century. Now we have modern
> languages such as Euphoria.
Oh goodie, lets go by 1970's thinks,, and not improve on them. I am so not a
fan of Dijkstra and Knuth. Most Ai coders i have read have it wrong too, as
the recent slow lingering death of Cyc finally proves. Doug Lenat is 1970's
vintage. Thirty years, many $millions, and people-decades later, it has
stalled and gone open source. Like all of Lenat's other projects. The theories
of mind and psyche are much more advanced since the 70's, see, no more
fridged moms causing Asperger's syndrome. Puter science has advanced
too. Not gaving a goto won't hurt Eu as much,, but denying us the use of it
because someone erroniously said it was bad FOR HIM 30 years ago,
because he could not follow the program flow in a few bad program designs
back then, is not a valid reason.
> And now, in our beloved elegant high level modern programming
> language, which encourages structured programming, you want to
> introduce this unstructured low level statement GOTO.
> I simply cannot understand why. There is no need for it.
> (Well, maybe so long as there is no enhancement of Euphoria's exit
> statement, there will be a little need. But the consequence should be
> to enhance the exit statement, not to introduce GOTO.)
The plain fact is, all the while-endwhile, repeat-until, case-endcase, break,
exit(), resume, and continue can be replaced with goto. That makes it
extremely versatile. In some cases it produces more readable code than a
list of boolean tests to skip "structured" code. That word "structured" is
getting a worse and worse taste in my mouth, when we are bowing to the
theory we must be confined in the straitjacket of prettyprinting the source in
the text editor. Once we are done processing deep in a nest of loops and
boolean tests, and it is time to go on to the next job, the fastest way there is
a straight line: goto.
> > and not to replace loops or if/switch statements or routines or any of
> > the stuff which should be seperated to be made more readable.)
>
> <snip>
>
> > I think that all features should be implemeted,
>
> I disagree. Anything that is not necessary one the one hand, and has
> the potential to cause harm one the other hand, should *not* be
> implemented.
Like hammers, knives, bowling balls, refridgerators, cars, plastics, cell
phones, paper cuts on my fingers, wet towels in locker rooms, hot water,
those loud jet engines, etc etc..
> > and that the programmer
> > should choose one's own style from there. (Of course Rob would never
> > agree to that, and I am better at Euphoria than I am with C, so I continue
> > to
> > write preproc to get around this limitation.
>
> Well, if you consider the lack of GOTO as a limitation, I can understand
> you, of course. For me this is not a limitation. I've been programming
> in PowerBASIC for about 10 years, there is GOTO of course.
> I simply never needed it.
Because you *can* get by without it doesn't mean you made the best
choice. I programmed in a language without *any* loops, goto worked nicely.
Consider Eu doesn't have a repeat-until loop, you haveto bracket a while-
endwhile with a if-then. Or a while-endwhile with an exit. Or no loops and a
goto. It's your *choice*, i would like to chose to use a goto in *some* cases.
Kat
13. Re: EOF and GOTO and 0th array element
On 0, Juergen Luethje <jluethje at gmx.de> wrote:
<big snip>
> > Such as I. With goto, exit/continue/exit(n)/next(n) would not be
> > needed.
> > Of course, with goto, for..end for/while..end while/if..end
> > if/select..end select or even procedure..end procedure/function..end
> > function wouldn't be needed either.
>
> Right, but there has been good reasons why Rob nevertheless decided to
> implement while..end while etc. in Euphoria.
> Arguing this way, I also could say Euphoria would not be needed at all,
> because programs can be written in assembler.
Sorry, I meant to add that goto is a bad idea for replacing
for/while/if/select
(select is something else the language could use!)/procedure/function.
goto
does have its uses, but I agree that totally uncontrolled gotos can
destroy
the readability of the code.
<big snip>
>
> The bottom line is, that GOTO is a low level statement, for which there
> is no place in a high level language like Euphoria. High level languages
> should encourage structured programming and structured thinking.
> GOTO doesn't do that. GOTO isn't necessary in a high level language such
> as Euphoria, but GOTO has the potential to produce "logical spaghetti",
> which will lead to less readable and less maintainable code.
> If I want to do low level coding, I'll do it in assembler -- it is much
> fun for me, I don't know a better low level language, and I can do as
> much conditional and unconditional jumps as I like. But I like
> Euphoria, because it is a high level language. And I would like it to
> remain a high level language.
>
> > My proposal: implement goto and goto-alternatives, and then let
> > the community decided which style is best by seeing which one is used
> > more often.
>
> "best" and "most often" aren't synonyms, unfortunately things are more
> complicated ...
> There are fairly enough other languages that provide GOTO. Why not keep
> at least one high level language clean?
>
My point is that the programmer should be able to decide whats best,
and not
the program language writter. Not to say I don't understand your
viewpoint
(I have also witnessed the uncontrolled goto spining out of control),
one
compromise would be to create a lgoto which can only be used to jump
out
of loops via labels, but thats exactly what the exit name statement
does.
Personally, I'd like to be able to choose which style I want on a whim,
but thats just my opinion.
> >>>> <quote>
> >>>> Many authors have suggested language features [...]
> >>>> which are expressed in terms of *exit*, *jump-out*,
> >>>> *break*, or *leave* statements. Kosaraju [57] has
> >>>> proved that such statements are sufficient to
> >>>> express all programs without *go to*'s and without
> >>>> any extra computation, but only if an exit from
> >>>> arbitrarily many levels of control is permitted.
> >>>> <unquote>
> >>>> [Knuth, Donald E.: Structured Programming with go to Statements.
> >>>> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
>
> <snip>
>
> > If used in a limited fashion, goto works fine with easily-readable
> > code.
>
> This is often said in this context. The decisive word is *if* ...
> After (not only) my experience, this is just a theoretical consideration.
> In practice, GOTO is *not* used in a limited fashion in (far too) many
> programs. I say this after having read *megabytes* of BASIC source code.
>
> > (i.e. used only to exit loops (entering would be too tricky)
>
> In a high level programming language, *structured* statements should be
> used for that purpose.
>
> <quote>
> What we really want is to conceive of our program in
> such a way that we rarely even /think/ about *go to*
> statements, because the real need for them hardly ever
> arises. The language in which we express our ideas has
> a strong influence on our thought processes. Therefore,
> Dijkstra [23] asks for more new language features --
> structures which encourage clear thinking -- in order
> to avoid the *go to*'s temptations toward complications.
> <unquote>
> [Knuth, Donald E.: Structured Programming with go to Statements.
> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
>
> This was written in the 70's of the last century. Now we have modern
> languages such as Euphoria.
> And now, in our beloved elegant high level modern programming
> language, which encourages structured programming, you want to
> introduce this unstructured low level statement GOTO.
> I simply cannot understand why. There is no need for it.
> (Well, maybe so long as there is no enhancement of Euphoria's exit
> statement, there will be a little need. But the consequence should be
> to enhance the exit statement, not to introduce GOTO.)
>
> > and not to replace loops or if/switch statements or routines or any of
> > the stuff which should be seperated to be made more readable.)
>
> <snip>
>
> > I think that all features should be implemeted,
>
> I disagree. Anything that is not necessary one the one hand, and has
> the potential to cause harm one the other hand, should *not* be
> implemented.
>
As of version Eu 2.3, goto or some alternative is necessary. And while
goto can create spagetti coding (I op for restricting use to routines
if this
is too big a problem, and this reduces the spagetti to procedures and
functions
only), I doubt very few people on this list would use it to do more
than
jump out of loops or to replace recursive routine calls.
> > and that the programmer
> > should choose one's own style from there. (Of course Rob would never
> > agree to that, and I am better at Euphoria than I am with C, so I continue
> > to write preproc to get around this limitation.
>
> Well, if you consider the lack of GOTO as a limitation, I can understand
> you, of course. For me this is not a limitation. I've been programming
> in PowerBASIC for about 10 years, there is GOTO of course.
> I simply never needed it.
>
I've needed it only on a few occasions, for jumping out of multiple
loops easily, and for speeding up recursive functions (in C mind you,
I've had to do without in Euphoria). But it is those few occasions
where
it does provide usefulness. I'm not trying to completely advocate goto,
but
mere propose it as an alternative.
> > And yes, writing a preproc to implement the goto statement is possible
> > (which I did with rparse, and David Cuny did with ebasic), although the
> > converted code is so messy it is a terrible idea.)
>
> > jbrown
>
> Just my 2 Euro cents.
>
> Best regards,
> Juergen
>
jbrown
--
14. Re: EOF and GOTO and 0th array element
Kat <gertie at PELL.NET> wrote:
> On 24 Aug 2002, at 11:41, Juergen Luethje wrote:
>> jbrown105 <jbrown105 at speedymail.org> wrote:
>>
>>> On 0, Juergen Luethje <jluethje at gmx.de> wrote:
>>>>
>>>> Hello Derek,
>>>>
>>>> Derek <ddparnell at bigpond.com> wrote:
>>
>> [Derek's proposal for enhancement of the exit statement]
>>
>>> Goto could be used for the same purpose.
>>
>> Technically speaking, this is correct of course. But that's not an
>> argument for the use of GOTO. Not anything that could be done, also
>> should be done. GOTO isn't necessary at all.
> But yet the assy code under Eu is full of them.
If "assy" should mean assembler, and you mean full of "jmp", I agree.
Actually the plain fact is, all the Euphoria code can be replaced with
assembler code. That makes assembler code extremely versatile. And as I
wrote before, we therefore don't need Euphoria at all.
>> <snip>
>>
>>>> the explicit GOTO statement, that is provided by BASIC and other
>>>> languages, and that obviously some people would like to see in
>>>> Euphoria.
>>
>>> Such as I. With goto, exit/continue/exit(n)/next(n) would not be
>>> needed.
>>> Of course, with goto, for..end for/while..end while/if..end
>>> if/select..end select or even procedure..end procedure/function..end
>>> function wouldn't be needed either.
>>
>> Right, but there has been good reasons why Rob nevertheless decided to
>> implement while..end while etc. in Euphoria.
>> Arguing this way, I also could say Euphoria would not be needed at all,
>> because programs can be written in assembler.
>>
>> The bottom line is, that GOTO is a low level statement, for which there
>> is no place in a high level language like Euphoria. High level languages
>> should encourage structured programming and structured thinking.
> Define "structured". You mean it looks nice when printed out in your text
> editor, right?
Yes, of course, what else could I mean? And I always print the vowels in
blue, and the consonants in red, so that it is guaranteed to look nice,
you know.
I'm very happy that you got a crystal ball, so that you could read my
mind, and know what I think, better than myself. Very nice! Please give
me your phone number, so that I always can call you, and ask you what I
think. Very, aehh.. "useful" indeed ...
Juergen
--
Difficile est satiram non scribere.
15. Re: EOF and GOTO and 0th array element
jbrown105 <jbrown105 at speedymail.org> wrote:
> On 0, Juergen Luethje <jluethje at gmx.de> wrote:
> <big snip>
>>> Such as I. With goto, exit/continue/exit(n)/next(n) would not be
>>> needed.
>>> Of course, with goto, for..end for/while..end while/if..end
>>> if/select..end select or even procedure..end procedure/function..end
>>> function wouldn't be needed either.
>>
>> Right, but there has been good reasons why Rob nevertheless decided to
>> implement while..end while etc. in Euphoria.
>> Arguing this way, I also could say Euphoria would not be needed at all,
>> because programs can be written in assembler.
> Sorry, I meant to add that goto is a bad idea for replacing
> for/while/if/select
> (select is something else the language could use!)/procedure/function.
> goto does have its uses, but I agree that totally uncontrolled gotos
> can destroy the readability of the code.
Thanks, now I understand what you meant.
<snip>
>>> I think that all features should be implemeted,
>>
>> I disagree. Anything that is not necessary one the one hand, and has
>> the potential to cause harm one the other hand, should *not* be
>> implemented.
>
> As of version Eu 2.3, goto or some alternative is necessary.
As I'm rather new to Euphoria, could you please tell me what new
features of version 2.3 made goto or some alternative necessary
in your opinion?
> And while goto can create spagetti coding (I op for restricting use to
> routines if this is too big a problem, and this reduces the spagetti
> to procedures and functions only), I doubt very few people on this
> list would use it to do more than jump out of loops or to replace
> recursive routine calls.
>>> and that the programmer
>>> should choose one's own style from there. (Of course Rob would never
>>> agree to that, and I am better at Euphoria than I am with C, so I continue
>>> to write preproc to get around this limitation.
>>
>> Well, if you consider the lack of GOTO as a limitation, I can understand
>> you, of course. For me this is not a limitation. I've been programming
>> in PowerBASIC for about 10 years, there is GOTO of course.
>> I simply never needed it.
> I've needed it only on a few occasions, for jumping out of multiple
> loops easily, and for speeding up recursive functions (in C mind you,
> I've had to do without in Euphoria). But it is those few occasions
> where it does provide usefulness. I'm not trying to completely
> advocate goto, but mere propose it as an alternative.
I think I understand your point of view.
About my point of view, I already wrote anything in my previous post,
I can't say something additional at the moment.
<just snipped the old stuff>
> jbrown
Best regards,
Juergen
16. Re: EOF and GOTO and 0th array element
Juergen,
Kat asked you a simple question: 'Define "structured".' Your little tantrum
indicates to me you are clueless - so please leave her alone!
And to you, Kat, give up! Bigotry of any kind, almost by definition, simply
cannot be defeated. The best you can do is to subvert the next generation...
jiri
17. Re: EOF and GOTO and 0th array element
On 0, Juergen Luethje <jluethje at gmx.de> wrote:
<big snip>
> >>> I think that all features should be implemeted,
> >>
> >> I disagree. Anything that is not necessary one the one hand, and has
> >> the potential to cause harm one the other hand, should *not* be
> >> implemented.
> >
> > As of version Eu 2.3, goto or some alternative is necessary.
>
> As I'm rather new to Euphoria, could you please tell me what new
> features of version 2.3 made goto or some alternative necessary
> in your opinion?
>
Basicly, the current lack of continue and exit n are the bigger issue.
As I have already stated, using gotos for inlining routines is also a
good idea,
although I also know that you don't deem this necessary.
<big snip>
> <just snipped the old stuff>
>
> > jbrown
>
> Best regards,
> Juergen
>
jbrown
--
18. Re: EOF and GOTO and 0th array element
Jiri wrote:
> Juergen,
> Kat asked you a simple question: 'Define "structured".' Your little tantrum
> indicates to me you are clueless - so please leave her alone!
That wasn't a tantrum, I just answered her post by following the PIPO
principle (polemic in, polemic out).
> And to you, Kat, give up! Bigotry of any kind,
What do you call "bigotry"? The fact, that jbrown and me had a serious
discussion about this topic? My decision, not to waste time with polemics?
> almost by definition, simply
> cannot be defeated. The best you can do is to subvert the next generation...
> jiri
Regards,
Juergen
19. Re: EOF and GOTO and 0th array element
Hello Juergen, Hello Derek,
> Îò: Juergen Luethje <jluethje at gmx.de>
> Êîìó: EUforum <EUforum at topica.com>
> Òåìà: Re: EOF and GOTO and 0th array element
> Äàòà: 23 àâãóñòà 2002 ã. 23:20
>
> Derek <ddparnell at bigpond.com> wrote:
>
> <snip>
> > I will argue against the "exit n" idea for
> > a number of reasons.
> > The first reason is that over time, the value
> > of 'n' might change as
> > modifications change the nesting level
> > of the 'exit' statement.
<snip>
This 'n' must be considered if it is 3 or more.
For 1 and 2, there are the simple old good
standard antispaghetti EU constructions,
for example:
procedure loop()
while x do
-- code 1
while y do
-- code 2
if a then return -- = exit 2
else exit -- = exit 1
end if
-- code 3
end while
-- code 4
if b then exit
end if
end while
end procedure
So, the question is - how frequently we use
3 and more nested loops - as a reason to
implement exit n.
This question has to have a simple answer -
let us search through 930+ archive packages
to find this too deep loops' percentage.
But I am too too lazy to search and to struggle
for this >=3 new feature in the interpreter,
sorry please, OK?
Who wants?
Regards,
Igor Kachan
kinz at peterlink.ru
20. Re: EOF and GOTO and 0th array element
Hello Igor,
either I didn't explain myself clearly enough or you missed reading the
section where I added an alternative to 'exit n'.
----- Original Message -----
From: "Igor Kachan" <kinz at peterlink.ru>
To: "EUforum" <EUforum at topica.com>
Subject: Re: EOF and GOTO and 0th array element
>>
> Derek <ddparnell at bigpond.com> wrote:
>>
>> <snip>
>> > I will argue against the "exit n" idea for
>> > a number of reasons.
>> > The first reason is that over time, the value
>> > of 'n' might change as
>> > modifications change the nesting level
>> > of the 'exit' statement.
>
><snip>
It is in the snipped part that I put forward an alternative to 'exit n'.
Maybe you would like to reread that section to see a fuller discussion.
In summary it is this: A simple way to exit deeply nested loops is a
desirable addition to the language. The idea of 'exit n' where 'n'
represents the current depth level is NOT the best idea. ****INSTEAD**** I
would propose that 'exit <name>' be used, where <name> is the name the
programmer gives to a specific loop block.
The reason is that the depth can change over time as the program is
modified, but a named loop block is unlikely to have a name change.
>This 'n' must be considered if it is 3 or more.
>
>For 1 and 2, there are the simple old good
>standard antispaghetti EU constructions,
>for example:
>
Here is my reworking of your example:
FileBlk:while x do
-- code 1
RecordBlk:while y do
-- code 2
if a then exit FileBlk
else exit RecordBlk
end if
-- code 3
end while
-- code 4
if b then exit FileBlk
end if
end while
As you can see, this scheme works just as well for any depth level of loop
block nesting. And even if some programmer later changes the depth level,
the code ALREADY written does not need changing per se.
>So, the question is - how frequently we use
>3 and more nested loops - as a reason to
>implement exit n.
>
>This question has to have a simple answer -
>let us search through 930+ archive packages
>to find this too deep loops' percentage.
>
>But I am too too lazy to search and to struggle
>for this >=3 new feature in the interpreter,
>sorry please, OK?
>
>Who wants?
As I have now explained (again) that sort of exercise is not required.
It is not the concept of exiting an arbitary depth of loops that I have
issue with, its the idea of enumerating that level on an 'exit' statement
that troubles me.
----------------
cheers,
Derek Parnell
21. Re: EOF and GOTO and 0th array element
Sorry, Juergen, your so called PIPO principle, is not a principle at all, it's
an unprincipled, provocative idiocy. But back to your question: "bigotry :
strongly held opinions or beliefs in defiance of reason or argument." Fits
perfectly.
jiri
----- Original Message -----
From: "Juergen Luethje" <jluethje at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: EOF and GOTO and 0th array element
>
> Jiri wrote:
>
> > Juergen,
>
> > Kat asked you a simple question: 'Define "structured".' Your little tantrum
> > indicates to me you are clueless - so please leave her alone!
>
> That wasn't a tantrum, I just answered her post by following the PIPO
> principle (polemic in, polemic out).
>
> > And to you, Kat, give up! Bigotry of any kind,
>
> What do you call "bigotry"? The fact, that jbrown and me had a serious
> discussion about this topic? My decision, not to waste time with polemics?
>
> > almost by definition, simply
> > cannot be defeated. The best you can do is to subvert the next generation...
>
> > jiri
>
> Regards,
> Juergen
>
>
>
>
22. Re: EOF and GOTO and 0th array element
Hello Derek,
Thank you very much, yes, your idea is very interesting
indeed, but my trouble was about the frequency of such
a programming aerobatics.
To know the real frequency someone can just research
the real archive and find all examples when programmer
needed complicated conditional exits from the deep loops.
I do not think there are too many such the cases in *real*
practice.
Anyway anyone can exit any loop's depth just now step by step.
Yes, construction will not be too short, but it is really
*rare* construction, I think.
Regards,
Igor Kachan
kinz at peterlink.ru
----------
> Îò: Derek Parnell <ddparnell at bigpond.com>
> Êîìó: EUforum <EUforum at topica.com>
> Òåìà: Re: EOF and GOTO and 0th array element
> Äàòà: 25 àâãóñòà 2002 ã. 15:17
>
> Hello Igor,
> either I didn't explain myself clearly enough or you missed reading the
> section where I added an alternative to 'exit n'.
>
> ----- Original Message -----
> From: "Igor Kachan" <kinz at peterlink.ru>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, August 25, 2002 4:44 PM
> Subject: Re: EOF and GOTO and 0th array element
>
> >>
> > Derek <ddparnell at bigpond.com> wrote:
> >>
> >> <snip>
> >> > I will argue against the "exit n" idea for
> >> > a number of reasons.
> >> > The first reason is that over time, the value
> >> > of 'n' might change as
> >> > modifications change the nesting level
> >> > of the 'exit' statement.
> >
> ><snip>
>
> It is in the snipped part that I put forward an alternative to 'exit n'.
> Maybe you would like to reread that section to see a fuller discussion.
>
> In summary it is this: A simple way to exit deeply nested loops is a
> desirable addition to the language. The idea of 'exit n' where 'n'
> represents the current depth level is NOT the best idea. ****INSTEAD****
I
> would propose that 'exit <name>' be used, where <name> is the name the
> programmer gives to a specific loop block.
>
> The reason is that the depth can change over time as the program is
> modified, but a named loop block is unlikely to have a name change.
>
> >This 'n' must be considered if it is 3 or more.
> >
> >For 1 and 2, there are the simple old good
> >standard antispaghetti EU constructions,
> >for example:
> >
>
> Here is my reworking of your example:
>
> FileBlk:while x do
> -- code 1
> RecordBlk:while y do
> -- code 2
> if a then exit FileBlk
> else exit RecordBlk
> end if
> -- code 3
> end while
> -- code 4
> if b then exit FileBlk
> end if
> end while
>
> As you can see, this scheme works just as well for any depth level of
loop
> block nesting. And even if some programmer later changes the depth level,
> the code ALREADY written does not need changing per se.
>
> >So, the question is - how frequently we use
> >3 and more nested loops - as a reason to
> >implement exit n.
> >
> >This question has to have a simple answer -
> >let us search through 930+ archive packages
> >to find this too deep loops' percentage.
> >
> >But I am too too lazy to search and to struggle
> >for this >=3 new feature in the interpreter,
> >sorry please, OK?
> >
> >Who wants?
>
> As I have now explained (again) that sort of exercise is not required.
>
> It is not the concept of exiting an arbitary depth of loops that I have
> issue with, its the idea of enumerating that level on an 'exit' statement
> that troubles me.
23. Re: EOF and GOTO and 0th array element
Yes Igor, I suspect you are correct. Looping depths of 3 or more would be
rare. Of course, some might argue it is rare because it is difficult to do
in the current language :)
On a relative scale, I would not be placing this proposed change to Euphoria
above a number of others that have been already mentioned.
----------------
cheers,
Derek Parnell
----- Original Message -----
From: "Igor Kachan" <kinz at peterlink.ru>
To: "EUforum" <EUforum at topica.com>
Sent: Sunday, August 25, 2002 10:05 PM
Subject: Re: EOF and GOTO and 0th array element
Hello Derek,
Thank you very much, yes, your idea is very interesting
indeed, but my trouble was about the frequency of such
a programming aerobatics.
To know the real frequency someone can just research
the real archive and find all examples when programmer
needed complicated conditional exits from the deep loops.
I do not think there are too many such the cases in *real*
practice.
Anyway anyone can exit any loop's depth just now step by step.
Yes, construction will not be too short, but it is really
*rare* construction, I think.
Regards,
Igor Kachan
kinz at peterlink.ru
----------
> Îò: Derek Parnell <ddparnell at bigpond.com>
> Êîìó: EUforum <EUforum at topica.com>
> Òåìà: Re: EOF and GOTO and 0th array element
> Äàòà: 25 àâãóñòà 2002 ã. 15:17
>
> Hello Igor,
> either I didn't explain myself clearly enough or you missed reading the
> section where I added an alternative to 'exit n'.
>
> ----- Original Message -----
> From: "Igor Kachan" <kinz at peterlink.ru>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, August 25, 2002 4:44 PM
> Subject: Re: EOF and GOTO and 0th array element
>
> >>
> > Derek <ddparnell at bigpond.com> wrote:
> >>
> >> <snip>
> >> > I will argue against the "exit n" idea for
> >> > a number of reasons.
> >> > The first reason is that over time, the value
> >> > of 'n' might change as
> >> > modifications change the nesting level
> >> > of the 'exit' statement.
> >
> ><snip>
>
> It is in the snipped part that I put forward an alternative to 'exit n'.
> Maybe you would like to reread that section to see a fuller discussion.
>
> In summary it is this: A simple way to exit deeply nested loops is a
> desirable addition to the language. The idea of 'exit n' where 'n'
> represents the current depth level is NOT the best idea. ****INSTEAD****
I
> would propose that 'exit <name>' be used, where <name> is the name the
> programmer gives to a specific loop block.
>
> The reason is that the depth can change over time as the program is
> modified, but a named loop block is unlikely to have a name change.
>
> >This 'n' must be considered if it is 3 or more.
> >
> >For 1 and 2, there are the simple old good
> >standard antispaghetti EU constructions,
> >for example:
> >
>
> Here is my reworking of your example:
>
> FileBlk:while x do
> -- code 1
> RecordBlk:while y do
> -- code 2
> if a then exit FileBlk
> else exit RecordBlk
> end if
> -- code 3
> end while
> -- code 4
> if b then exit FileBlk
> end if
> end while
>
> As you can see, this scheme works just as well for any depth level of
loop
> block nesting. And even if some programmer later changes the depth level,
> the code ALREADY written does not need changing per se.
>
> >So, the question is - how frequently we use
> >3 and more nested loops - as a reason to
> >implement exit n.
> >
> >This question has to have a simple answer -
> >let us search through 930+ archive packages
> >to find this too deep loops' percentage.
> >
> >But I am too too lazy to search and to struggle
> >for this >=3 new feature in the interpreter,
> >sorry please, OK?
> >
> >Who wants?
>
> As I have now explained (again) that sort of exercise is not required.
>
> It is not the concept of exiting an arbitary depth of loops that I have
> issue with, its the idea of enumerating that level on an 'exit' statement
> that troubles me.
24. Re: EOF and GOTO and 0th array element
On 25 Aug 2002, at 10:44, Igor Kachan wrote:
>
> Hello Juergen, Hello Derek,
>
> > Îò: Juergen Luethje <jluethje at gmx.de>
> > Êîìó: EUforum <EUforum at topica.com>
> > Òåìà: Re: EOF and GOTO and 0th array element
> > Äàòà: 23 àâãóñòà 2002 ã. 23:20
> >
> > Derek <ddparnell at bigpond.com> wrote:
> >
> > <snip>
> > > I will argue against the "exit n" idea for
> > > a number of reasons.
> > > The first reason is that over time, the value
> > > of 'n' might change as
> > > modifications change the nesting level
> > > of the 'exit' statement.
>
> <snip>
>
> This 'n' must be considered if it is 3 or more.
>
> For 1 and 2, there are the simple old good
> standard antispaghetti EU constructions,
> for example:
>
> procedure loop()
> while x do
> -- code 1
> while y do
> -- code 2
> if a then return -- = exit 2
> else exit -- = exit 1
> end if
> -- code 3
> end while
> -- code 4
> if b then exit
> end if
> end while
> end procedure
>
> So, the question is - how frequently we use
> 3 and more nested loops - as a reason to
> implement exit n.
>
> This question has to have a simple answer -
> let us search through 930+ archive packages
> to find this too deep loops' percentage.
>
> But I am too too lazy to search and to struggle
> for this >=3 new feature in the interpreter,
> sorry please, OK?
>
> Who wants?
NOT ME. I prefer the simple goto you already did.
Kat
26. Re: EOF and GOTO and 0th array element
On 25 Aug 2002, at 8:05, Juergen Luethje wrote:
>
> Jiri wrote:
>
> > Juergen,
>
> > Kat asked you a simple question: 'Define "structured".' Your little tantrum
> > indicates to me you are clueless - so please leave her alone!
>
> That wasn't a tantrum, I just answered her post by following the PIPO
> principle (polemic in, polemic out).
So how DO you define "structured programming" ?
> > And to you, Kat, give up! Bigotry of any kind,
>
> What do you call "bigotry"? The fact, that jbrown and me had a serious
> discussion about this topic? My decision, not to waste time with polemics?
No, that you have an illogical and indefensable position, wich you will defend
without looking at the evidence. It looks like you are saying you are right
because you say so. You even run from defining the terms you bandy about.
Kat
27. Re: EOF and GOTO and 0th array element
Jiri <jbabor at PARADISE.NET.NZ> wrote:
> Sorry, Juergen, your so called PIPO principle, is not a principle at
> all, it's an unprincipled, provocative idiocy.
Ah, if you say so, it of course must be THE TRUTH(tm).
> But back to your question: "bigotry :
> strongly held opinions or beliefs in defiance of reason or argument."
> Fits perfectly.
Yes, fits well to what you are doing here: don't contributing anything
to the topic, but grumbling instead.
As I wrote before, I don't like to waste my time with such things.
Therefore, for me it's <EOT> here.
> jiri
> ----- Original Message -----
<snip>
Juergen
28. Re: EOF and GOTO and 0th array element
On 25 Aug 2002, at 19:41, Juergen Luethje wrote:
>
> Jiri <jbabor at PARADISE.NET.NZ> wrote:
>
> > Sorry, Juergen, your so called PIPO principle, is not a principle at
> > all, it's an unprincipled, provocative idiocy.
>
> Ah, if you say so, it of course must be THE TRUTH(tm).
Coming from Jiri, it very well may be. He may have been programming longer
than you or i have been alive.
> > But back to your question: "bigotry :
> > strongly held opinions or beliefs in defiance of reason or argument."
> > Fits perfectly.
>
> Yes, fits well to what you are doing here: don't contributing anything
> to the topic, but grumbling instead.
>
> As I wrote before, I don't like to waste my time with such things.
> Therefore, for me it's <EOT> here.
This is so sad for being a programmers listserv. Juergen, Jiri is one of the
smartest people here, and has experience to back up what he says. And he
researches his answers before he offers them.
Basicly, i would pay to see goto in Eu, and i *do* buy registered Eu. Like
anything else, if you don't want to use it, don't. No one is forcing you to play
chess or basketball or use goto. It would be insignificant to the size or speed
of Eu to add goto, and i seriously doubt anyone would quit using Eu because
of it.
Kat
29. Re: EOF and GOTO and 0th array element
> >This question has to have a simple answer -
> >let us search through 930+ archive packages
> >to find this too deep loops' percentage.
> >
> >But I am too too lazy to search and to struggle
> >for this >=3 new feature in the interpreter,
> >sorry please, OK?
> >
> >Who wants?
>
> As I have now explained (again) that sort of exercise is not required.
exit
end if
end for
exit
end if
end for
end if
end for
end if
end if
end for
end if
end if
IDE_design.ew, lines 2025-2037, Judith's IDE v 0.13 BE#2
--------
Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.
Linus Torvalds, linux/Documentation/CodingStyle
--------
Wow! I've just returned home and I see a goto discussion again!
Martin
30. Re: EOF and GOTO and 0th array element
At 13:25 25/08/02 -0500, you wrote:
<snip>
>Basicly, i would pay to see goto in Eu, and i *do* buy registered Eu. Like
>anything else, if you don't want to use it, don't. No one is forcing you
to play
>chess or basketball or use goto. It would be insignificant to the size or
speed
>of Eu to add goto, and i seriously doubt anyone would quit using Eu because
>of it.
>
>Kat
<snip>
I'm no fan of goto but I agree with you Kat that if Euphoria had a goto I
wouldn't really complain now (my opinion is mellowing). I learnt to
program with BASIC and used (and no doubt abused) the goto statement. Well
in BASIC you had to.
I then learnt machine code (Z80 and then 6502). Because I could directly
apply my programming techniques of BASIC (assignment, math, testing
conditions and conditional branching) into machine code it was easier to
pick up than I thought.
Then I went to study Computer Science and we were all "weaned" off BASIC,
told that GOTO was bad and that "structured" languages like Pascal were
best. Well I learnt Pascal the way "they" wanted us to and it was an
education. I like to code in the "structured way" now but I'm not
advocating we all do so and that if we don't we are somehow BAD.
And anyway Pascal _HAS_ a goto statement. I can't recall the exact syntax
because I never used it - mainly because it was a sure fire way to have
your assignment downgraded
Now I think of it C has a goto in it somewhere. It behaves even more badly
via the longjmp.h include file. But wait, I code in C as well (well when I
have to) but I never use goto.
So basically I don't mind if Euphoria has goto. It won't bother me because
I won't use it. And guess what, I won't moan if anyone does use it
It could be argued that the more structured folks will be upset when they
have to look at unstructured code (i.e. code with goto statements). Well
maybe you might have a point but just because code is structured (and I
mean in this sense it is "goto" free) doesn't mean it is any more readable
than code with a few gotos in it. Proof? Hey I can send you some of my
Euphoria code that'll have you wincing and thinking "who the blazes codes
like this?" where there isn't a goto in sight
Regards,
Andy Cranston.
