1. Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Fernando Bauer wrote:
>
> Suppose we have GOTO and this kind of code (which I think is common):
> }}}
<eucode>
> procedure proc1()
> if cond1 then
> .. some code here ..
> if cond2 then
> .. some code here ..
> if cond3 then
> .. some code here ..
> goto OUT
> end if
> .. some code here ..
> end if
> .. some code here ..
> end if
> OUT:
> .. some code here ..
> end procedure
> </eucode>
{{{
>
> In Eu 3.1, a possible implementation would be:
> }}}
<eucode>
> procedure proc1()
> for i=1 to 1 do
> if cond1 then
> .. some code here ..
> if cond2 then
> .. some code here ..
> if cond3 then
> .. some code here ..
> exit
> end if
> .. some code here ..
> end if
> .. some code here ..
> end if
> end for
> .. some code here ..
> end procedure
> </eucode>
{{{
>
> Now, without GOTO, we are forced to (mis)use a loop construct (for-loop,
> while-loop)
> where there is NO loop.
> Conceptually, IMHO this makes no sense.
> To avoid the conceptual problem we could use flags, but IMHO this is even
> worst.
>
> Regards,
> Fernando
All non-goto code has been about making code flow as through a tree. Up a
trunk,
choosing major branches, to smaller branches (routines) and going into twigs
(loops, blocks) and then returning through the points until finally getting to
a leaf and exiting. This loop idiom to replace goto is something I have
forgotten but I did this once. What you see as an argument that goto can make
clearer code I see as an argument that there are times we want to implement
this kind of control flow but we lack something in the language so we either
implement with goto or with a loop.
You have avoided spegetti code but that does look like misuse. Goto is also
useful for porting from other languages, and there are times
you wish to jump to another neighboring twig but do not want to put the overhead
of a function call to do it. So, we need goto. Yet, the reason why we have
loops and multi-line if/blocks is because it usually easier if we divide the
kinds
of jumps we are doing into kinds. Is it a loop? Is it an if block? Is
it a loop with an integer counter (for)?
I feel there is a "missing" kind of structure for putting things in non-looping
block and being able to jump out of it as though it were a loop with exit. The
one iteration loop works but it isn't a loop semantically speaking.
The keywords while, for, and multi-line if blocks exist because people decided
that they would replace some usages with goto with control structures that could
be easier to read. These are all replacements of usages of goto. The control
structure for replaces a usage of goto or of while more directly. We all agree
these were good changes even if goto still has a place. I think Fernando has
hit
on a usage of for which could further be put into a different kind of control
structure.
So, I want you to think of a new keyword that the developers
might decide to put into 5.0 but we mustn't keep changing the target of 4.0
or nobody will ever be able to finish it
(we will see Starcraft II in stores first, the cows will come home first).
Shawn Pringle
2. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Shawn Pringle wrote:
>
> Fernando Bauer wrote:
> >
> > Suppose we have GOTO and this kind of code (which I think is common):
> > }}}
<eucode>
> > procedure proc1()
> > if cond1 then
> > .. some code here ..
> > if cond2 then
> > .. some code here ..
> > if cond3 then
> > .. some code here ..
> > goto OUT
> > end if
> > .. some code here ..
> > end if
> > .. some code here ..
> > end if
> > OUT:
> > .. some code here ..
> > end procedure
> > </eucode>
{{{
> >
> > In Eu 3.1, a possible implementation would be:
> > }}}
<eucode>
> > procedure proc1()
> > for i=1 to 1 do
> > if cond1 then
> > .. some code here ..
> > if cond2 then
> > .. some code here ..
> > if cond3 then
> > .. some code here ..
> > exit
> > end if
> > .. some code here ..
> > end if
> > .. some code here ..
> > end if
> > end for
> > .. some code here ..
> > end procedure
> > </eucode>
{{{
> >
> > Now, without GOTO, we are forced to (mis)use a loop construct (for-loop,
> > while-loop)
> > where there is NO loop.
> > Conceptually, IMHO this makes no sense.
> > To avoid the conceptual problem we could use flags, but IMHO this is even
> > worst.
> >
> > Regards,
> > Fernando
>
> All non-goto code has been about making code flow as through a tree. Up a
> trunk,
> choosing major branches, to smaller branches (routines) and going into twigs
>
> (loops, blocks) and then returning through the points until finally getting
> to
> a leaf and exiting. This loop idiom to replace goto is something I have
> forgotten but I did this once. What you see as an argument that goto can make
>
> clearer code I see as an argument that there are times we want to implement
> this kind of control flow but we lack something in the language so we either
>
> implement with goto or with a loop.
>
> You have avoided spegetti code but that does look like misuse. Goto is also
> useful for porting from other languages, and there are times
> you wish to jump to another neighboring twig but do not want to put the
> overhead
> of a function call to do it. So, we need goto. Yet, the reason why we have
> loops and multi-line if/blocks is because it usually easier if we divide the
> kinds
> of jumps we are doing into kinds. Is it a loop? Is it an if block? Is
> it a loop with an integer counter (for)?
>
> I feel there is a "missing" kind of structure for putting things in
> non-looping
> block and being able to jump out of it as though it were a loop with exit.
> The
> one iteration loop works but it isn't a loop semantically speaking.
>
> The keywords while, for, and multi-line if blocks exist because people decided
> that they would replace some usages with goto with control structures that
> could
>
> be easier to read. These are all replacements of usages of goto. The control
>
> structure for replaces a usage of goto or of while more directly. We all
> agree
>
> these were good changes even if goto still has a place. I think Fernando has
> hit
> on a usage of for which could further be put into a different kind of control
>
> structure.
>
> So, I want you to think of a new keyword that the developers
> might decide to put into 5.0 but we mustn't keep changing the target of 4.0
>
> or nobody will ever be able to finish it
> (we will see Starcraft II in stores first, the cows will come home first).
>
>
> Shawn Pringle
I've been thinking along the same lines, except that I don' believe that all the
patterns can be defined with the precision needed to fix on one, or even two,
constructs. One of the problems is that the same concept might appear in many
different forms. You might test the "condition" of sequence data with an 'if'
block, or loop through its elements, or use a while 1 construct, or just a series
of top-level code. The most you can say about the pattern is that:-
- A group of constructs execute some testing of data
- The data either fails early, in which case you want to fall through, but maybe
not right to the end - maybe to an error point,
- or it triggers a retry, and you want to go back, but quite likely not to pass
through all the same hoops again.
It struck me that part of the lack of structure of the goto comes from the
single label approach, rather than defining a block of code. If you could label a
block of code, it would have more meaning. Just say you chose the keyword
'during' with a label. Code like Fernando's would look more structured:-
procedure proc1()
-- preliminary code
during data_filtering
if cond1 then
-- code here
if cond2 then
-- code modifying data
retry data_filtering
if cond3 then
exit data_filtering
end if
-- code here
end if
-- code here
end if
end data_filtering
-- clean_up code
end procedure
This really does nothing more than labelled jumps, but the labelling of the code
as a meaningful block makes it more structured.
Of course, someone will say you could just wrap the innards in another procedure
and use return to exit, and something else for retry, but that doesn't detract
from Fernando's and your point that the language lacks a construct to represent a
common logical pattern.
And like you, I won't be holding my breath for something like this to appear in
the language, which is why I'm settling for the current proposal.
Cheers
Peter Robinson
3. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Peter Robinson wrote:
>
> Shawn Pringle wrote:
> >
> > Fernando Bauer wrote:
> > >
> > > Suppose we have GOTO and this kind of code (which I think is common):
> > > }}}
<eucode>
> > > procedure proc1()
> > > if cond1 then
> > > .. some code here ..
> > > if cond2 then
> > > .. some code here ..
> > > if cond3 then
> > > .. some code here ..
> > > goto OUT
> > > end if
> > > .. some code here ..
> > > end if
> > > .. some code here ..
> > > end if
> > > OUT:
> > > .. some code here ..
> > > end procedure
> > > </eucode>
{{{
> > >
> > > In Eu 3.1, a possible implementation would be:
> > > }}}
<eucode>
> > > procedure proc1()
> > > for i=1 to 1 do
> > > if cond1 then
> > > .. some code here ..
> > > if cond2 then
> > > .. some code here ..
> > > if cond3 then
> > > .. some code here ..
> > > exit
> > > end if
> > > .. some code here ..
> > > end if
> > > .. some code here ..
> > > end if
> > > end for
> > > .. some code here ..
> > > end procedure
> > > </eucode>
{{{
> > >
> > > Now, without GOTO, we are forced to (mis)use a loop construct (for-loop,
> > > while-loop)
> > > where there is NO loop.
> > > Conceptually, IMHO this makes no sense.
> > > To avoid the conceptual problem we could use flags, but IMHO this is even
> > > worst.
> > >
> > > Regards,
> > > Fernando
> >
> > All non-goto code has been about making code flow as through a tree. Up a
> > trunk,
> > choosing major branches, to smaller branches (routines) and going into twigs
> >
> > (loops, blocks) and then returning through the points until finally getting
> > to
> > a leaf and exiting. This loop idiom to replace goto is something I have
> > forgotten but I did this once. What you see as an argument that goto can
> > make
> >
> > clearer code I see as an argument that there are times we want to implement
> > this kind of control flow but we lack something in the language so we either
> >
> > implement with goto or with a loop.
> >
> > You have avoided spegetti code but that does look like misuse. Goto is also
> > useful for porting from other languages, and there are times
> > you wish to jump to another neighboring twig but do not want to put the
> > overhead
> > of a function call to do it. So, we need goto. Yet, the reason why we have
> > loops and multi-line if/blocks is because it usually easier if we divide the
> > kinds
> > of jumps we are doing into kinds. Is it a loop? Is it an if block? Is
> > it a loop with an integer counter (for)?
> >
> > I feel there is a "missing" kind of structure for putting things in
> > non-looping
> > block and being able to jump out of it as though it were a loop with exit.
> > The
> > one iteration loop works but it isn't a loop semantically speaking.
> >
> > The keywords while, for, and multi-line if blocks exist because people
> > decided
> > that they would replace some usages with goto with control structures that
> > could
> >
> > be easier to read. These are all replacements of usages of goto. The
> > control
> >
> > structure for replaces a usage of goto or of while more directly. We all
> > agree
> >
> > these were good changes even if goto still has a place. I think Fernando
> > has
> > hit
> > on a usage of for which could further be put into a different kind of
> > control
> >
> > structure.
> >
> > So, I want you to think of a new keyword that the developers
> > might decide to put into 5.0 but we mustn't keep changing the target of 4.0
> >
> > or nobody will ever be able to finish it
> > (we will see Starcraft II in stores first, the cows will come home first).
> >
> >
> > Shawn Pringle
>
> I've been thinking along the same lines, except that I don' believe that all
> the patterns can be defined with the precision needed to fix on one, or even
> two, constructs. One of the problems is that the same concept might appear in
> many different forms. You might test the "condition" of sequence data with an
> 'if' block, or loop through its elements, or use a while 1 construct, or just
> a series of top-level code. The most you can say about the pattern is that:-
>
> - A group of constructs execute some testing of data
> - The data either fails early, in which case you want to fall through, but
> maybe
> not right to the end - maybe to an error point,
> - or it triggers a retry, and you want to go back, but quite likely not to
> pass
> through all the same hoops again.
>
> It struck me that part of the lack of structure of the goto comes from the
> single
> label approach, rather than defining a block of code. If you could label a
> block
> of code, it would have more meaning. Just say you chose the keyword 'during'
> with a label. Code like Fernando's would look more structured:-
>
> procedure proc1()
> -- preliminary code
> during data_filtering
> if cond1 then
> -- code here
> if cond2 then
> -- code modifying data
> retry data_filtering
> if cond3 then
> exit data_filtering
> end if
> -- code here
> end if
> -- code here
> end if
> end data_filtering
> -- clean_up code
> end procedure
>
> This really does nothing more than labelled jumps, but the labelling of the
> code as a meaningful block makes it more structured.
>
> Of course, someone will say you could just wrap the innards in another
> procedure
> and use return to exit, and something else for retry, but that doesn't detract
> from Fernando's and your point that the language lacks a construct to
> represent
> a common logical pattern.
>
> And like you, I won't be holding my breath for something like this to appear
> in the language, which is why I'm settling for the current proposal.
>
> Cheers
> Peter Robinson
I think goto still has a place, but I would agree to a block construct such as
suggested. I would prefer block/end block to during though I think.
Aside from creating a place to break out from without abusing the intent of
other constructs, it would provide a way to create nested private scopes.
In my opinion all the various types of code blocks should be able to be
targettable break points, not just loops. A block construct would be a universal
solution.
Code is Alchemy
4. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Chris Bensler wrote:
>
> Peter Robinson wrote:
> >
> > Shawn Pringle wrote:
> > >
> > > Fernando Bauer wrote:
> > > >
> > > > Suppose we have GOTO and this kind of code (which I think is common):
> > > > }}}
<eucode>
> > > > procedure proc1()
> > > > if cond1 then
> > > > .. some code here ..
> > > > if cond2 then
> > > > .. some code here ..
> > > > if cond3 then
> > > > .. some code here ..
> > > > goto OUT
> > > > end if
> > > > .. some code here ..
> > > > end if
> > > > .. some code here ..
> > > > end if
> > > > OUT:
> > > > .. some code here ..
> > > > end procedure
> > > > </eucode>
{{{
> > > >
> > > > In Eu 3.1, a possible implementation would be:
> > > > }}}
<eucode>
> > > > procedure proc1()
> > > > for i=1 to 1 do
> > > > if cond1 then
> > > > .. some code here ..
> > > > if cond2 then
> > > > .. some code here ..
> > > > if cond3 then
> > > > .. some code here ..
> > > > exit
> > > > end if
> > > > .. some code here ..
> > > > end if
> > > > .. some code here ..
> > > > end if
> > > > end for
> > > > .. some code here ..
> > > > end procedure
> > > > </eucode>
{{{
> > > >
> > > > Now, without GOTO, we are forced to (mis)use a loop construct (for-loop,
> while-loop)</font></i>
> > > > where there is NO loop.
> > > > Conceptually, IMHO this makes no sense.
> > > > To avoid the conceptual problem we could use flags, but IMHO this is
> > > > even
> worst.</font></i>
> > > >
> > > > Regards,
> > > > Fernando
> > >
> > > All non-goto code has been about making code flow as through a tree. Up a
> > > trunk,
> > > choosing major branches, to smaller branches (routines) and going into
> > > twigs
> > >
> > > (loops, blocks) and then returning through the points until finally
> > > getting
> > > to
> > > a leaf and exiting. This loop idiom to replace goto is something I have
> > > forgotten but I did this once. What you see as an argument that goto can
> > > make
> > >
> > > clearer code I see as an argument that there are times we want to
> > > implement
> > > this kind of control flow but we lack something in the language so we
> > > either
> > >
> > > implement with goto or with a loop.
> > >
> > > You have avoided spegetti code but that does look like misuse. Goto is
> > > also
> > > useful for porting from other languages, and there are times
> > > you wish to jump to another neighboring twig but do not want to put the
> > > overhead
> > > of a function call to do it. So, we need goto. Yet, the reason why we
> > > have
> > > loops and multi-line if/blocks is because it usually easier if we divide
> > > the
> > > kinds
> > > of jumps we are doing into kinds. Is it a loop? Is it an if block? Is
> > > it a loop with an integer counter (for)?
> > >
> > > I feel there is a "missing" kind of structure for putting things in
> > > non-looping
> > > block and being able to jump out of it as though it were a loop with exit.
> > >
> > > The
> > > one iteration loop works but it isn't a loop semantically speaking.
> > >
> > > The keywords while, for, and multi-line if blocks exist because people
> > > decided
> > > that they would replace some usages with goto with control structures that
> > > could
> > >
> > > be easier to read. These are all replacements of usages of goto. The
> > > control
> > >
> > > structure for replaces a usage of goto or of while more directly. We all
> > > agree
> > >
> > > these were good changes even if goto still has a place. I think Fernando
> > > has
> > > hit
> > > on a usage of for which could further be put into a different kind of
> > > control
> > >
> > > structure.
> > >
> > > So, I want you to think of a new keyword that the developers
> > > might decide to put into 5.0 but we mustn't keep changing the target of
> > > 4.0
> > >
> > > or nobody will ever be able to finish it
> > > (we will see Starcraft II in stores first, the cows will come home first).
> > >
> > >
> > > Shawn Pringle
> >
> > I've been thinking along the same lines, except that I don' believe that all
> > the patterns can be defined with the precision needed to fix on one, or even
> > two, constructs. One of the problems is that the same concept might appear
> > in
> > many different forms. You might test the "condition" of sequence data with
> > an
> > 'if' block, or loop through its elements, or use a while 1 construct, or
> > just
> > a series of top-level code. The most you can say about the pattern is that:-
> >
> > - A group of constructs execute some testing of data
> > - The data either fails early, in which case you want to fall through, but
> > maybe
> > not right to the end - maybe to an error point,
> > - or it triggers a retry, and you want to go back, but quite likely not to
> > pass
> > through all the same hoops again.
> >
> > It struck me that part of the lack of structure of the goto comes from the
> > single
> > label approach, rather than defining a block of code. If you could label a
> > block
> > of code, it would have more meaning. Just say you chose the keyword 'during'
> > with a label. Code like Fernando's would look more structured:-
> >
> > procedure proc1()
> > -- preliminary code
> > during data_filtering
> > if cond1 then
> > -- code here
> > if cond2 then
> > -- code modifying data
> > retry data_filtering
> > if cond3 then
> > exit data_filtering
> > end if
> > -- code here
> > end if
> > -- code here
> > end if
> > end data_filtering
> > -- clean_up code
> > end procedure
> >
> > This really does nothing more than labelled jumps, but the labelling of the
> > code as a meaningful block makes it more structured.
> >
> > Of course, someone will say you could just wrap the innards in another
> > procedure
> > and use return to exit, and something else for retry, but that doesn't
> > detract
> > from Fernando's and your point that the language lacks a construct to
> > represent
> > a common logical pattern.
> >
> > And like you, I won't be holding my breath for something like this to appear
> > in the language, which is why I'm settling for the current proposal.
> >
> > Cheers
> > Peter Robinson
>
> I think goto still has a place, but I would agree to a block construct such
> as suggested. I would prefer block/end block to during though I think.
> Aside from creating a place to break out from without abusing the intent of
> other constructs, it would provide a way to create nested private scopes.
>
> In my opinion all the various types of code blocks should be able to be
> targettable
> break points, not just loops. A block construct would be a universal solution.
>
> Code is Alchemy
I really appreciate all your comments and ideas, thanks!
Maybe it's still possible to extend the use of labels to 'if-then-else'
construct.
I read somewhere this kind of syntax:
for i = 1 to length(s) label "xyz" do
For now, by analogy and for completeness, maybe we could have this:
if ..cond.. label "xyz" then
Regards,
Fernando
5. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Fernando Bauer wrote:
>
> Chris Bensler wrote:
> >
> > Peter Robinson wrote:
> > >
> > > Shawn Pringle wrote:
> > > >
> > > > Fernando Bauer wrote:
> > > > >
> > > > > Suppose we have GOTO and this kind of code (which I think is common):
> > > > > }}}
<eucode>
> > > > > procedure proc1()
> > > > > if cond1 then
> > > > > .. some code here ..
> > > > > if cond2 then
> > > > > .. some code here ..
> > > > > if cond3 then
> > > > > .. some code here ..
> > > > > goto OUT
> > > > > end if
> > > > > .. some code here ..
> > > > > end if
> > > > > .. some code here ..
> > > > > end if
> > > > > OUT:
> > > > > .. some code here ..
> > > > > end procedure
> > > > > </eucode>
{{{
> > > > >
> > > > > In Eu 3.1, a possible implementation would be:
> > > > > }}}
<eucode>
> > > > > procedure proc1()
> > > > > for i=1 to 1 do
> > > > > if cond1 then
> > > > > .. some code here ..
> > > > > if cond2 then
> > > > > .. some code here ..
> > > > > if cond3 then
> > > > > .. some code here ..
> > > > > exit
> > > > > end if
> > > > > .. some code here ..
> > > > > end if
> > > > > .. some code here ..
> > > > > end if
> > > > > end for
> > > > > .. some code here ..
> > > > > end procedure
> > > > > </eucode>
{{{
> > > > >
> > > > > Now, without GOTO, we are forced to (mis)use a loop construct
> > > > > (for-loop,
> > while-loop)</font></i>
> > > > > where there is NO loop.
> > > > > Conceptually, IMHO this makes no sense.
> > > > > To avoid the conceptual problem we could use flags, but IMHO this is
> > > > > even
> > worst.</font></i>
> > > > >
> > > > > Regards,
> > > > > Fernando
> > > >
> > > > All non-goto code has been about making code flow as through a tree. Up
> > > > a
> trunk,</font></i>
> > > > choosing major branches, to smaller branches (routines) and going into
> > > > twigs
> > > >
> > > > (loops, blocks) and then returning through the points until finally
> > > > getting
> > > > to
> > > > a leaf and exiting. This loop idiom to replace goto is something I have
> > > >
> > > > forgotten but I did this once. What you see as an argument that goto
> > > > can make
> > > >
> > > > clearer code I see as an argument that there are times we want to
> > > > implement
> > > > this kind of control flow but we lack something in the language so we
> > > > either
> > > >
> > > > implement with goto or with a loop.
> > > >
> > > > You have avoided spegetti code but that does look like misuse. Goto is
> > > > also
> > > > useful for porting from other languages, and there are times
> > > > you wish to jump to another neighboring twig but do not want to put the
> > > > overhead
> > > > of a function call to do it. So, we need goto. Yet, the reason why we
> > > > have
> > > > loops and multi-line if/blocks is because it usually easier if we divide
> > > > the
> > > > kinds
> > > > of jumps we are doing into kinds. Is it a loop? Is it an if block? Is
> > > > it a loop with an integer counter (for)?
> > > >
> > > > I feel there is a "missing" kind of structure for putting things in
> > > > non-looping
> > > > block and being able to jump out of it as though it were a loop with
> > > > exit.
> > > > The
> > > > one iteration loop works but it isn't a loop semantically speaking.
> > > >
> > > > The keywords while, for, and multi-line if blocks exist because people
> > > > decided
> > > > that they would replace some usages with goto with control structures
> > > > that
> could</font></i>
> > > >
> > > > be easier to read. These are all replacements of usages of goto. The
> > > > control
> > > >
> > > > structure for replaces a usage of goto or of while more directly. We
> > > > all agree
> > > >
> > > > these were good changes even if goto still has a place. I think
> > > > Fernando has
> > > > hit
> > > > on a usage of for which could further be put into a different kind of
> > > > control
> > > >
> > > > structure.
> > > >
> > > > So, I want you to think of a new keyword that the developers
> > > > might decide to put into 5.0 but we mustn't keep changing the target of
> > > > 4.0
> > > >
> > > > or nobody will ever be able to finish it
> > > > (we will see Starcraft II in stores first, the cows will come home
> > > > first).
> > > >
> > > >
> > > > Shawn Pringle
> > >
> > > I've been thinking along the same lines, except that I don' believe that
> > > all
> > > the patterns can be defined with the precision needed to fix on one, or
> > > even
> > > two, constructs. One of the problems is that the same concept might appear
> > > in
> > > many different forms. You might test the "condition" of sequence data with
> > > an
> > > 'if' block, or loop through its elements, or use a while 1 construct, or
> > > just
> > > a series of top-level code. The most you can say about the pattern is
> > > that:-
> > >
> > > - A group of constructs execute some testing of data
> > > - The data either fails early, in which case you want to fall through, but
> > > maybe
> > > not right to the end - maybe to an error point,
> > > - or it triggers a retry, and you want to go back, but quite likely not to
> > > pass
> > > through all the same hoops again.
> > >
> > > It struck me that part of the lack of structure of the goto comes from the
> > > single
> > > label approach, rather than defining a block of code. If you could label a
> > > block
> > > of code, it would have more meaning. Just say you chose the keyword
> > > 'during'
> > > with a label. Code like Fernando's would look more structured:-
> > >
> > > procedure proc1()
> > > -- preliminary code
> > > during data_filtering
> > > if cond1 then
> > > -- code here
> > > if cond2 then
> > > -- code modifying data
> > > retry data_filtering
> > > if cond3 then
> > > exit data_filtering
> > > end if
> > > -- code here
> > > end if
> > > -- code here
> > > end if
> > > end data_filtering
> > > -- clean_up code
> > > end procedure
> > >
> > > This really does nothing more than labelled jumps, but the labelling of
> > > the
> > > code as a meaningful block makes it more structured.
> > >
> > > Of course, someone will say you could just wrap the innards in another
> > > procedure
> > > and use return to exit, and something else for retry, but that doesn't
> > > detract
> > > from Fernando's and your point that the language lacks a construct to
> > > represent
> > > a common logical pattern.
> > >
> > > And like you, I won't be holding my breath for something like this to
> > > appear
> > > in the language, which is why I'm settling for the current proposal.
> > >
> > > Cheers
> > > Peter Robinson
> >
> > I think goto still has a place, but I would agree to a block construct such
> > as suggested. I would prefer block/end block to during though I think.
> > Aside from creating a place to break out from without abusing the intent of
> > other constructs, it would provide a way to create nested private scopes.
> >
> > In my opinion all the various types of code blocks should be able to be
> > targettable
> > break points, not just loops. A block construct would be a universal
> > solution.
> >
> > Code is Alchemy
>
> I really appreciate all your comments and ideas, thanks!
> Maybe it's still possible to extend the use of labels to 'if-then-else'
> construct.
> I read somewhere this kind of syntax:
> for i = 1 to length(s) label "xyz" do
>
> For now, by analogy and for completeness, maybe we could have this:
> if ..cond.. label "xyz" then
>
> Regards,
> Fernando
IMO, the use of the label keyword in the other constructs is kludgy, it seems
too much like a combination of statements to me. I would prefer if labels could
be applied to each construct intrisincally instead of using an explicit label
keyword. Just make it more natural and evident somehow. At the least, the labels
need to be unburied. They are far to difficult to detect. I also think that the
use of the label keyword detracts more from readability than the lack of any
explicit specifier.
Consider something like this...
for count = get_start_index(addrList[handle]) to stop_index(addrList[handle]) by
get_element_size(addrList[handle]) label "foo" do -- counts the number of
elements in the range of start to stop
if count = x then exit "foo" end if
end for
vs.
for "foo" count = get_start_index(addrList[handle]) to
stop_index(addrList[handle]) by get_element_size(addrList[handle]) do -- counts
the number of elements in the range of start to stop
if count = x then exit "foo" end if
end for
Or keep the label keyword, it's just my preference not to need it.. but the
syntax should still be changed so that the labels come at the beginning of the
statement, not the end.
I think generally when one peruses some source code, the main thing we are
interested in is code flow, not the specific details of every single statement.
Chris Bensler
Code is Alchemy
6. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
- Posted by CChris <christian.cuvier at ?griculture.gouv.?r>
Jun 07, 2008
-
Last edited Jun 08, 2008
Fernando Bauer wrote:
>
> Chris Bensler wrote:
> >
> > Peter Robinson wrote:
> > >
> > > Shawn Pringle wrote:
> > > >
> > > > Fernando Bauer wrote:
> > > > >
> > > > > Suppose we have GOTO and this kind of code (which I think is common):
> > > > > }}}
<eucode>
> > > > > procedure proc1()
> > > > > if cond1 then
> > > > > .. some code here ..
> > > > > if cond2 then
> > > > > .. some code here ..
> > > > > if cond3 then
> > > > > .. some code here ..
> > > > > goto OUT
> > > > > end if
> > > > > .. some code here ..
> > > > > end if
> > > > > .. some code here ..
> > > > > end if
> > > > > OUT:
> > > > > .. some code here ..
> > > > > end procedure
> > > > > </eucode>
{{{
> > > > >
> > > > > In Eu 3.1, a possible implementation would be:
> > > > > }}}
<eucode>
> > > > > procedure proc1()
> > > > > for i=1 to 1 do
> > > > > if cond1 then
> > > > > .. some code here ..
> > > > > if cond2 then
> > > > > .. some code here ..
> > > > > if cond3 then
> > > > > .. some code here ..
> > > > > exit
> > > > > end if
> > > > > .. some code here ..
> > > > > end if
> > > > > .. some code here ..
> > > > > end if
> > > > > end for
> > > > > .. some code here ..
> > > > > end procedure
> > > > > </eucode>
{{{
> > > > >
> > > > > Now, without GOTO, we are forced to (mis)use a loop construct
> > > > > (for-loop,
> > while-loop)</font></i>
> > > > > where there is NO loop.
> > > > > Conceptually, IMHO this makes no sense.
> > > > > To avoid the conceptual problem we could use flags, but IMHO this is
> > > > > even
> > worst.</font></i>
> > > > >
> > > > > Regards,
> > > > > Fernando
> > > >
> > > > All non-goto code has been about making code flow as through a tree. Up
> > > > a
> trunk,</font></i>
> > > > choosing major branches, to smaller branches (routines) and going into
> > > > twigs
> > > >
> > > > (loops, blocks) and then returning through the points until finally
> > > > getting
> > > > to
> > > > a leaf and exiting. This loop idiom to replace goto is something I have
> > > >
> > > > forgotten but I did this once. What you see as an argument that goto
> > > > can make
> > > >
> > > > clearer code I see as an argument that there are times we want to
> > > > implement
> > > > this kind of control flow but we lack something in the language so we
> > > > either
> > > >
> > > > implement with goto or with a loop.
> > > >
> > > > You have avoided spegetti code but that does look like misuse. Goto is
> > > > also
> > > > useful for porting from other languages, and there are times
> > > > you wish to jump to another neighboring twig but do not want to put the
> > > > overhead
> > > > of a function call to do it. So, we need goto. Yet, the reason why we
> > > > have
> > > > loops and multi-line if/blocks is because it usually easier if we divide
> > > > the
> > > > kinds
> > > > of jumps we are doing into kinds. Is it a loop? Is it an if block? Is
> > > > it a loop with an integer counter (for)?
> > > >
> > > > I feel there is a "missing" kind of structure for putting things in
> > > > non-looping
> > > > block and being able to jump out of it as though it were a loop with
> > > > exit.
> > > > The
> > > > one iteration loop works but it isn't a loop semantically speaking.
> > > >
> > > > The keywords while, for, and multi-line if blocks exist because people
> > > > decided
> > > > that they would replace some usages with goto with control structures
> > > > that
> could</font></i>
> > > >
> > > > be easier to read. These are all replacements of usages of goto. The
> > > > control
> > > >
> > > > structure for replaces a usage of goto or of while more directly. We
> > > > all agree
> > > >
> > > > these were good changes even if goto still has a place. I think
> > > > Fernando has
> > > > hit
> > > > on a usage of for which could further be put into a different kind of
> > > > control
> > > >
> > > > structure.
> > > >
> > > > So, I want you to think of a new keyword that the developers
> > > > might decide to put into 5.0 but we mustn't keep changing the target of
> > > > 4.0
> > > >
> > > > or nobody will ever be able to finish it
> > > > (we will see Starcraft II in stores first, the cows will come home
> > > > first).
> > > >
> > > >
> > > > Shawn Pringle
> > >
> > > I've been thinking along the same lines, except that I don' believe that
> > > all
> > > the patterns can be defined with the precision needed to fix on one, or
> > > even
> > > two, constructs. One of the problems is that the same concept might appear
> > > in
> > > many different forms. You might test the "condition" of sequence data with
> > > an
> > > 'if' block, or loop through its elements, or use a while 1 construct, or
> > > just
> > > a series of top-level code. The most you can say about the pattern is
> > > that:-
> > >
> > > - A group of constructs execute some testing of data
> > > - The data either fails early, in which case you want to fall through, but
> > > maybe
> > > not right to the end - maybe to an error point,
> > > - or it triggers a retry, and you want to go back, but quite likely not to
> > > pass
> > > through all the same hoops again.
> > >
> > > It struck me that part of the lack of structure of the goto comes from the
> > > single
> > > label approach, rather than defining a block of code. If you could label a
> > > block
> > > of code, it would have more meaning. Just say you chose the keyword
> > > 'during'
> > > with a label. Code like Fernando's would look more structured:-
> > >
> > > procedure proc1()
> > > -- preliminary code
> > > during data_filtering
> > > if cond1 then
> > > -- code here
> > > if cond2 then
> > > -- code modifying data
> > > retry data_filtering
> > > if cond3 then
> > > exit data_filtering
> > > end if
> > > -- code here
> > > end if
> > > -- code here
> > > end if
> > > end data_filtering
> > > -- clean_up code
> > > end procedure
> > >
> > > This really does nothing more than labelled jumps, but the labelling of
> > > the
> > > code as a meaningful block makes it more structured.
> > >
> > > Of course, someone will say you could just wrap the innards in another
> > > procedure
> > > and use return to exit, and something else for retry, but that doesn't
> > > detract
> > > from Fernando's and your point that the language lacks a construct to
> > > represent
> > > a common logical pattern.
> > >
> > > And like you, I won't be holding my breath for something like this to
> > > appear
> > > in the language, which is why I'm settling for the current proposal.
> > >
> > > Cheers
> > > Peter Robinson
> >
> > I think goto still has a place, but I would agree to a block construct such
> > as suggested. I would prefer block/end block to during though I think.
> > Aside from creating a place to break out from without abusing the intent of
> > other constructs, it would provide a way to create nested private scopes.
> >
> > In my opinion all the various types of code blocks should be able to be
> > targettable
> > break points, not just loops. A block construct would be a universal
> > solution.
> >
> > Code is Alchemy
>
> I really appreciate all your comments and ideas, thanks!
> Maybe it's still possible to extend the use of labels to 'if-then-else'
> construct.
> I read somewhere this kind of syntax:
> for i = 1 to length(s) label "xyz" do
>
> For now, by analogy and for completeness, maybe we could have this:
> if ..cond.. label "xyz" then
>
> Regards,
> Fernando
It is implemented in v4.0 already.
if-blocks can have labels too, and "break" breaks out of them.
CChris
7. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
- Posted by Matt Lewis <matthewwalkerlewis at gmail.?o?>
Jun 07, 2008
-
Last edited Jun 08, 2008
Chris Bensler wrote:
>
<note the very large snip...please>
> }}}
<eucode>
> for "foo" count = get_start_index(addrList[handle]) to
> stop_index(addrList[handle])
> by get_element_size(addrList[handle]) do -- counts the number of elements in
> the range of start to stop
> if count = x then exit "foo" end if
> end for
> </eucode>
{{{
I think this definitely has some serious merit.
Matt
8. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
- Posted by Chris Bensler <eu at ?reati?eportal.ca>
Jun 07, 2008
-
Last edited Jun 08, 2008
CChris wrote:
<SNIP> (Matt's comment noted ;)
> It is implemented in v4.0 already.
>
> if-blocks can have labels too, and "break" breaks out of them.
>
> CChris
Excellent, a block construct would still be a valid addition though.
Chris Bensler
Code is Alchemy
9. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Matt Lewis wrote:
>
> Chris Bensler wrote:
> >
>
> <note the very large snip...please>
>
> > }}}
<eucode>
> > for "foo" count = get_start_index(addrList[handle]) to
> > stop_index(addrList[handle])
> > by get_element_size(addrList[handle]) do -- counts the number of elements
> in the range of start to stop
> > if count = x then exit "foo" end if
> > end for
> > </eucode>
{{{
>
> I think this definitely has some serious merit.
>
> Matt
I don't get it, Matt.
Are you saying that you favour general jumps like this:
<code1>
label foo
<code2>
label bar
<code3>
where the jump could come from any of the code segments and go to any label
within scope?
But disapprove something like this:
start block
<code1>
end block
where:-
1. the jump-off point must fall between the defined start and end;
2. the jump must go to an enclosing label, rather than any label in the file;
3. the construct mirrors existing blocks, except that existing blocks have
boundary conditions attached;
4. the existing proposal for goto allows the second construct to be done in
almost exactly that form (adapting the precise syntax of course), but without the
assurances referred to in 1 and 2?
Cheers
Peter Robinson
10. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Matt Lewis wrote:
>
> Chris Bensler wrote:
> >
>
> <note the very large snip...please>
>
> > }}}
<eucode>
> > for "foo" count = get_start_index(addrList[handle]) to
> > stop_index(addrList[handle])
> > by get_element_size(addrList[handle]) do -- counts the number of elements
> in the range of start to stop
> > if count = x then exit "foo" end if
> > end for
> > </eucode>
{{{
>
> I think this definitely has some serious merit.
>
> Matt
I had suggested, on the dev list, to use start of header as an alternate
location for the label clause, precisely on these grounds. But it was argued that
there shouldn't be two different places.
I still think a label keyword is clearer there. Actually, the label name stands
out more if besides it.
CChris
11. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Peter Robinson wrote:
>
> Matt Lewis wrote:
> >
> > Chris Bensler wrote:
> > >
> >
> > <note the very large snip...please>
> >
> > > }}}
<eucode>
> > > for "foo" count = get_start_index(addrList[handle]) to
> > > stop_index(addrList[handle])
> > > by get_element_size(addrList[handle]) do -- counts the number of elements
> > in the range of start to stop
> > > if count = x then exit "foo" end if
> > > end for
> > > </eucode>
{{{
> >
> > I think this definitely has some serious merit.
> >
>
> I don't get it, Matt.
In this post I was simply saying that Chris' proposal for labeling loops
looked better than the current syntax.
> Are you saying that you favour general jumps like this:
>
> <code1>
> label foo
> <code2>
> label bar
> <code3>
>
> where the jump could come from any of the code segments and go to any label
> within scope?
>
> But disapprove something like this:
>
> start block
> <code1>
> end block
>
> where:-
>
> 1. the jump-off point must fall between the defined start and end;
> 2. the jump must go to an enclosing label, rather than any label in the file;
> 3. the construct mirrors existing blocks, except that existing blocks have
> boundary
> conditions attached;
> 4. the existing proposal for goto allows the second construct to be done in
> almost exactly that form (adapting the precise syntax of course), but without
> the assurances referred to in 1 and 2?
But, yes, if we're going to have goto, I don't see the usefulness of
the more limited approach you've given here.
Matt
12. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
CChris wrote:
[snipped]
> > Maybe it's still possible to extend the use of labels to 'if-then-else'
> > construct.
> > I read somewhere this kind of syntax:
> > for i = 1 to length(s) label "xyz" do
> >
> > For now, by analogy and for completeness, maybe we could have this:
> > if ..cond.. label "xyz" then
> >
> > Regards,
> > Fernando
>
> It is implemented in v4.0 already.
>
> if-blocks can have labels too, and "break" breaks out of them.
>
> CChris
Using labels (ex. break "xyz"), why add another keyword ("break") when "exit",
which IMHO has the same meaning, could be used instead?
Without using labels, ok, "break" could be used to distinguish an exit from a
if-then-else construct from an exit from a loop, but is this a sufficient reason
to add it?
Regards,
Fernando
13. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Fernando Bauer wrote:
>
> Using labels (ex. break "xyz"), why add another keyword ("break") when "exit",
> which IMHO has the same meaning, could be used instead?
>
> Without using labels, ok, "break" could be used to distinguish an exit from
> a if-then-else construct from an exit from a loop, but is this a sufficient
> reason to add it?
>
> Regards,
> Fernando
Some are going to say we need exits to exit the loop of the enclosing if
block instead of the if. I assume we all mean:
We want:
for i = 1 to 2000 do
if i*i > 100 then
exit
end if
end for
to mean:
for label "loop" i = 1 to 2000 do
if label "condition" i*i > 100 then
exit "loop"
end if
end for
and not:
for label "loop" i = 1 to 2000 do
if label "condition" i*i > 100 then
exit "condition"
end if
end for
There is no reason we cannot have 3.1 behavior for exit without labels and
this other break behavior when it has a label.
Shawn Pringle
14. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Fernando Bauer wrote:
>
> CChris wrote:
>
> [snipped]
>
> > > Maybe it's still possible to extend the use of labels to 'if-then-else'
> > > construct.
> > > I read somewhere this kind of syntax:
> > > for i = 1 to length(s) label "xyz" do
> > >
> > > For now, by analogy and for completeness, maybe we could have this:
> > > if ..cond.. label "xyz" then
> > >
> > > Regards,
> > > Fernando
> >
> > It is implemented in v4.0 already.
> >
> > if-blocks can have labels too, and "break" breaks out of them.
> >
> > CChris
>
> Using labels (ex. break "xyz"), why add another keyword ("break") when "exit",
> which IMHO has the same meaning, could be used instead?
>
> Without using labels, ok, "break" could be used to distinguish an exit from
> a if-then-else construct from an exit from a loop, but is this a sufficient
> reason to add it?
>
> Regards,
> Fernando
If there is no label or number, your change will break any code that has an eit
statement inside an if block inside a loop. Same would apply with numbered
statements.
And introducing a different behaviour for unlabelled and labelled statements
doesn't look good imho.
CChris
15. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Matt Lewis wrote:
>
>
> But, yes, if we're going to have goto, I don't see the usefulness of
> the more limited approach you've given here.
>
> Matt
Why do we need any constructs if we could do the same thing with goto?
Goto is low-level, it should not be a replacement for higher level constructs
which provide structure.
Chris Bensler
Code is Alchemy
16. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Chris Bensler wrote:
>
> Matt Lewis wrote:
> >
> >
> > But, yes, if we're going to have goto, I don't see the usefulness of
> > the more limited approach you've given here.
> >
> > Matt
>
> Why do we need any constructs if we could do the same thing with goto?
> Goto is low-level, it should not be a replacement for higher level constructs
> which provide structure.
>
> Chris Bensler
> Code is Alchemy
Your post is an oxymoron.
Since goto is low level, and since its use is better confined to to when higher,
more maintainable constructs fail to do the jo in some way, then it has to
coexist with them. Makes sense?
CChris
17. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
CChris wrote:
>
> Chris Bensler wrote:
> >
> > Why do we need any constructs if we could do the same thing with goto?
> > Goto is low-level, it should not be a replacement for higher level
> > constructs
> > which provide structure.
> >
> > Chris Bensler
> > Code is Alchemy
>
> Your post is an oxymoron.
> Since goto is low level, and since its use is better confined to to when
> higher,
> more maintainable constructs fail to do the jo in some way, then it has to
> coexist
> with them. Makes sense?
>
> CChris
You should re-read his post. We are not talking about getting rid of goto but
using new constructs that can be used inplace of goto when the flow is forward.
Shawn Pringle
18. Re: Replacing GOTO. [was Re: Conceptual problem solved by GOTO]
Shawn Pringle wrote:
>
> CChris wrote:
> >
> > Chris Bensler wrote:
> > >
> > > Why do we need any constructs if we could do the same thing with goto?
> > > Goto is low-level, it should not be a replacement for higher level
> > > constructs
> > > which provide structure.
> > >
> > > Chris Bensler
> > > Code is Alchemy
> >
> > Your post is an oxymoron.
> > Since goto is low level, and since its use is better confined to to when
> > higher,
> > more maintainable constructs fail to do the jo in some way, then it has to
> > coexist
> > with them. Makes sense?
> >
> > CChris
>
> You should re-read his post. We are not talking about getting rid of goto but
> using new constructs that can be used inplace of goto when the flow is
> forward.
>
>
> Shawn Pringle
Me too. Ly point is that highrt lrvrl constructs must be there _because_ goto is
so liw level.
CChris
