do while control loop ?

320 views
Skip to first unread message

Ross Mohn

unread,
Feb 2, 2000, 3:00:00 AM2/2/00
to
Is there a standard Tcl implementation of a do while control loop out there?
I have one, but I have some questions about it.
Thanks.
-Ross Mohn
RPM...@panix.com
http://www.waxandwane.com/


Bob Techentin

unread,
Feb 3, 2000, 3:00:00 AM2/3/00
to
David Cuthbert wrote:
>
> Bogdan Petculescu wrote:
> > Ross, you could remain in really standard Tcl with
> > an infinite loop simulating a 'repeat ... until' like:
> >
> > while {1} {
> > ...
> > if {exit_condition} then {break}
> > }
> >
> > without needing any extra stuff.
>
> Oh... ouch. I don't know... I think this argues for a do {} while {}
> extension. I have a strong distaste for testing loop conditions anywhere
> except at the ends of the loop -- after C/C++ casts, they're arguably the
> largest source of bugs in our code and the hardest to test. I naturally
> look for exit conditions at the top of the loop (unless I see a do or
> switch).
>
> Dave

OK. I'll take a crack at it. Should be easy to add control structures
in Tcl, right? Hmmmm. OK. A little more complicated than I thought,
because you've got to 'uplevel' things, and I don't usually do that.
How does this look?


proc do { body whileword condition } {

if { $whileword != "while" } {
error "should be \"do body while condition\""
}

while {1} {
uplevel 1 $body

if { [uplevel 1 "expr $condition"] } {
continue
} else {
break
}
}
}

Might be nice to make the "while" keyword optional. But this seems to
work for me.

Bob
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html

Allen Flick

unread,
Feb 3, 2000, 3:00:00 AM2/3/00
to
Bob Techentin wrote:

> OK. I'll take a crack at it. <snip> <snip>


>
> proc do { body whileword condition } {
>
> if { $whileword != "while" } {
> error "should be \"do body while condition\""
> }
>
> while {1} {
> uplevel 1 $body
>
> if { [uplevel 1 "expr $condition"] } {
> continue
> } else {
> break
> }
> }
> }

=========================================
Or, if you want a repeat until loop
=========================================

proc repeat { body untilword condition } {

if {![string match "until" $untilword]} {
error "should be \"repeat body until condition\""
}

while {1} {
uplevel 1 $body

if { [uplevel 1 "expr $condition"] } break
}; #end while
}; # end proc


=========================================
Allen Flick: Research is what I'm doing
when I don't know what I'm doing.
=========================================

Bryan Oakley

unread,
Feb 3, 2000, 3:00:00 AM2/3/00
to
"David Cuthbert" <da...@kanga.org> wrote in message
news:38991993...@kanga.org...

> Bogdan Petculescu wrote:
> > Ross, you could remain in really standard Tcl with
> > an infinite loop simulating a 'repeat ... until' like:
> >
> > while {1} {
> > ...
> > if {exit_condition} then {break}
> > }
> >
> > without needing any extra stuff.
>
> Oh... ouch. I don't know... I think this argues for a do {} while {}
> extension. I have a strong distaste for testing loop conditions anywhere
> except at the ends of the loop -- after C/C++ casts, they're arguably the
> largest source of bugs in our code and the hardest to test. I naturally
> look for exit conditions at the top of the loop (unless I see a do or
> switch).

I find this sort of thing amusing. You prefer one syntax over the other,
when functionally the two are identical. What's the point? The code still
works the same and is still just as maintainable. Arguably *more*
maintainable than picking a solution that requires a non-standard tcl
construct.

Nevertheless, it's easy enough to write your own do command. I can think of
at least two ways to write this; here is one off the top of my head (and not
tested):

proc do {body while condition} {
if {![string match "while" $while]} {
error "incorrect usage: should be do body while condition"
}
set body "$body\nif {$condition} {continue} {break}"
uplevel [list while 1 $body]
}

....
set i 0
do {
puts "i is $i"
incr i
} while {$i < 10}

Does that suit your needs? It adds a tiny performance penalty, but it's a
"real" do command.


Jeffrey Hobbs

unread,
Feb 3, 2000, 3:00:00 AM2/3/00
to David Cuthbert
David Cuthbert wrote:
>
> Bogdan Petculescu wrote:
> > Ross, you could remain in really standard Tcl with
> > an infinite loop simulating a 'repeat ... until' like:
> >
> > while {1} {
> > ...
> > if {exit_condition} then {break}
> > }
> >
> > without needing any extra stuff.
>
> Oh... ouch. I don't know... I think this argues for a do {} while {}
> extension. I have a strong distaste for testing loop conditions anywhere
> except at the ends of the loop -- after C/C++ casts, they're arguably the
> largest source of bugs in our code and the hardest to test. I naturally
> look for exit conditions at the top of the loop (unless I see a do or
> switch).

Here's one I have in a little benchmark testing suite for Tcl:

proc do {body while cond} {
if {[string compare while $while]} {
return -code error "usage: do body while condition"


}
while {1} {
uplevel 1 $body

if {![uplevel 1 [list expr $cond]]} { break }
}
}

It's similar to some others posted, but this is pedantically the
most correct (could use some more error checking).

--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.

Andreas Kupries

unread,
Feb 3, 2000, 3:00:00 AM2/3/00
to

Bob Techentin <techenti...@mayo.edu> writes:

> > Bogdan Petculescu wrote:
> > > Ross, you could remain in really standard Tcl with
> > > an infinite loop simulating a 'repeat ... until' like:

> OK. I'll take a crack at it. Should be easy to add control
> structures in Tcl, right? Hmmmm. OK. A little more complicated
> than I thought, because you've got to 'uplevel' things, and I don't
> usually do that. How does this look?


> proc do { body whileword condition } {
>
> if { $whileword != "while" } {

> error "should be \"do body while condition\""


> }

> while {1} {
> uplevel 1 $body

Change the uplevel to

set fail [catch {uplevel 1 $body} msg]
switch -- $fail {
0 {
# ok
}
1 {
# error, throw upward.
return -code error \
-errorinfo $errorInfo \
-errorcode $errorCode $msg}

2 {
# return, throw upward.
return -code return $msg
}
3 {
# break, stop execution, no error
return {}
}
4 {
# continue
}
default {
# user defined code, throw upward.
return -code $res
}
}

to handle 'continue' and 'break' in the $body. More complexity, but
necessary for a control structure.



> if { [uplevel 1 "expr $condition"] } {
> continue
> } else {
> break
> }
> }
> }

> Might be nice to make the "while" keyword optional. But this seems
> to work for me.

--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.purl.org/NET/akupries/>
<http://www.usenix.org/events/tcl2k/> Are you coming too ?
-------------------------------------------------------------------------------

David Cuthbert

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
Bryan Oakley wrote:
> I find this sort of thing amusing. You prefer one syntax over the other,
> when functionally the two are identical. What's the point? The code still
> works the same and is still just as maintainable.

There is one important difference: where the exit points are located. Of
course, you're correct in saying that the two are functionally identical.
However, I really dislike loops that have termination conditions in the body
of the loop. They're a large source of bugs in our code.

> Arguably *more*
> maintainable than picking a solution that requires a non-standard tcl
> construct.

True, but I don't think that anyone reading the code wouldn't realise what
function the do {} while {} is performing. (And if they don't, they should
go back to marketing :-).

I didn't mean for anyone to write actual code. I'm somewhat amused, though,
that none of the submissions will handle the following correctly:

do { break } while {1}

(Yeah, yeah... here I go off about having termination conditions in the
body, and post a test case that has one. :-)

Dave

Frederic BONNET

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
Hi all,

Jeffrey Hobbs wrote:

> proc do {body while cond} {
> if {[string compare while $while]} {

> return -code error "usage: do body while condition"


> }
> while {1} {
> uplevel 1 $body

^^^^^^^^^^^^^^^

Let's add:

if {[set code [catch {uplevel 1 $body} result]]} {
return -code $code $result
}

for exception handling (break/continue/return/error). A little more work is
needed to manage error reporting properly (errorCode and errorInfo variables).

> if {![uplevel 1 [list expr $cond]]} { break }
> }
> }

--
Frédéric BONNET frederi...@ciril.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain


Donal K. Fellows

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
In article <389990CC...@mayo.edu>,

Bob Techentin <techenti...@mayo.edu> wrote:
> OK. I'll take a crack at it. Should be easy to add control structures
> in Tcl, right? Hmmmm. OK. A little more complicated than I thought,
> because you've got to 'uplevel' things, and I don't usually do that.
> How does this look?

I'll enhance it for 8.3 (mainly a few nips and tucks around the
[uplevel] commands. :^)

proc do {body whileword condition} {

if {![string equal $whileword while]} {
error "should be \"do body while condition\""


}
while {1} {
uplevel 1 $body

if {![uplevel 1 [list expr $condition]]} {break}
}
}

Donal (The Campaign for Efficient Tcl Usage, a.k.a. CETUS)
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Bob Techentin

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
Andreas Kupries wrote:
>
> Change the uplevel to
>
> set fail [catch {uplevel 1 $body} msg]
> switch -- $fail {
> 0 {
> # ok
> }

Eeeeew. I hadn't even thought of catching the errors. I was under the
mistaken impression that any errors in the uplevel get thrown upwards
from there. I now realize that the errors actually get thrown back down
into the 'do' proc, then back up again.

I remember reading a while back that "Tcl is soooo general, you can
write your own control structures." But I guess it is a little more
complicated than that.

Thanks,

Alexandre Ferrieux

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
Bob Techentin wrote:
>
> Andreas Kupries wrote:
> >
> > Change the uplevel to
> >
> > set fail [catch {uplevel 1 $body} msg]
> > switch -- $fail {
> > 0 {
> > # ok
> > }
>
> Eeeeew. I hadn't even thought of catching the errors. I was under the
> mistaken impression that any errors in the uplevel get thrown upwards
> from there. I now realize that the errors actually get thrown back down
> into the 'do' proc, then back up again.
>
> I remember reading a while back that "Tcl is soooo general, you can
> write your own control structures." But I guess it is a little more
> complicated than that.

Notice that you need this correction only to get rid of the extra layer
of 'invoked from within "uplevel 1 $body"...' in $errorInfo. If you can
live with it (and hence 'detect' hand-made control structs...), then it
is not complicated at all:-)

-Alex

Bryan Oakley

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
"David Cuthbert" <da...@kanga.org> wrote in message
news:389A3C72...@kanga.org...

> Bryan Oakley wrote:
> > I find this sort of thing amusing. You prefer one syntax over the other,
> > when functionally the two are identical. What's the point? The code
still
> > works the same and is still just as maintainable.
>
> There is one important difference: where the exit points are located. Of
> course, you're correct in saying that the two are functionally identical.
> However, I really dislike loops that have termination conditions in the
body
> of the loop. They're a large source of bugs in our code.

There must be more to it than what you say. If you truly have a single
termination condiation as the absolute last statement in a while, that will
never be more or less buggy than a do ... while statement with the
termination statement as an argument to "do". Perhaps you aren't rigid
enough in enforcing that the termination is the very last statement. If that
is the case, I agree, it can lead to errors in the code.

Perhaps that is what you are after -- a construct that forces the condition
to be at the end, rather than one that merely allows it.

[snip]

> I didn't mean for anyone to write actual code. I'm somewhat amused,
though,
> that none of the submissions will handle the following correctly:
>
> do { break } while {1}

I believe the one I posted earlier does.

proc do {body while condition} {
if {![string match "while" $while]} {

error "usage: do body while condition"
}

set body "$body\nif {$condition} {continue} {break}"
uplevel [list while 1 $body]
}

do {
break
puts "drat! we didn't break"
} while 1

Try it! You'll notice it doesn't ever execute the puts statement. Still,
it's not perfect, I'll admit. But it does work in your edge case :-)


Don Porter

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
Andreas Kupries wrote:
>> > set fail [catch {uplevel 1 $body} msg]
>> > switch -- $fail {
>> > 0 {
>> > # ok
>> > }
... and more

Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> Notice that you need this correction only to get rid of the extra layer
> of 'invoked from within "uplevel 1 $body"...' in $errorInfo.

Not so. Look at the full code again. You need it to properly handle
the return codes "break" and "continue".

Removing the extra entry in $::errorInfo is a nice finishing touch,
but the code Andrea posted didn't even attempt that. It's also
more complicated than it first appears, see

http://www.deja.com/=dnc/getdoc.xp?AN=468519243

Management of $::errorInfo might be easier if it were maintained
as a Tcl list rather than a string, with each level lappending
a single element. Any thoughts about that for 9.0?

--
| Don Porter, D.Sc. Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
|______________________________________________________________________|

Don Porter

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
Don Porter <d...@cam.nist.gov> wrote:
>...but the code Andrea posted didn't even attempt that.

Sorry about the typo, AndreaS. ( *@*&!@*# spellcheck ...)

Joe English

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
Jeffrey Hobbs <jeffre...@scriptics.com> wrote:

>Here's one I have in a little benchmark testing suite for Tcl:
>

>proc do {body while cond} {
> if {[string compare while $while]} {

> return -code error "usage: do body while condition"


> }
> while {1} {
> uplevel 1 $body

> if {![uplevel 1 [list expr $cond]]} { break }
> }
>}
>
>It's similar to some others posted, but this is pedantically the
>most correct (could use some more error checking).

Hmm...

set x 1
do {
puts "pre: $x"
incr x
if {$x % 3} { continue }
puts "post: $x"
} while {$x < 10}

--Joe English

jeng...@flightlab.com

Jeffrey Hobbs

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to Joe English

Right, that's due to the lack of "error" checking, which more
correctly should be called "return code" checking. A correct
response was posted in the thread. By pedantically correct,
I was referring to the use of [list] more than anything else.

Andreas Kupries

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to

d...@clover.cam.nist.gov (Don Porter) writes:

>Andreas Kupries wrote:
>>> > set fail [catch {uplevel 1 $body} msg]
>>> > switch -- $fail {
>>> > 0 {
>>> > # ok
>>> > }
>... and more

>Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
>> Notice that you need this correction only to get rid of the extra layer
>> of 'invoked from within "uplevel 1 $body"...' in $errorInfo.

> Not so. Look at the full code again. You need it to properly handle
> the return codes "break" and "continue".

Correct. I should mention that I just saw that Bryan posted a version
which I think does not need my big switch to do this. He constructs a
complete while statement from body and condition and then executes
that via 'uplevel'. So the 'while' itself will/should take care of
'break' and 'continue'.


> Removing the extra entry in $::errorInfo is a nice finishing touch,
> but the code Andrea posted didn't even attempt that. It's also more
> complicated than it first appears, see

> http://www.deja.com/=dnc/getdoc.xp?AN=468519243

> Management of $::errorInfo might be easier if it were maintained as
> a Tcl list rather than a string, with each level lappending a single
> element. Any thoughts about that for 9.0?

Oh, interesting idea.

Andreas Kupries

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to

d...@clover.cam.nist.gov (Don Porter) writes:

> Don Porter <d...@cam.nist.gov> wrote:
> >...but the code Andrea posted didn't even attempt that.
>
> Sorry about the typo, AndreaS. ( *@*&!@*# spellcheck ...)

:-) No problem.

Christopher Nelson

unread,
Feb 4, 2000, 3:00:00 AM2/4/00
to
Bogdan Petculescu wrote:
>
> Ross, you could remain in really standard Tcl with
> an infinite loop simulating a 'repeat ... until' like:
>
> while {1} {
> ...
> if {exit_condition} then {break}
> }
>
> without needing any extra stuff.

There's a repeat/until implementation in the [return] example from my book. The
source is posted on my web site (see he URL in the .sig below).

Chris
--
Christopher Nelson, Sr. Software Engineer Pinebush Technologies, Inc.
Author: Tcl/Tk Programmer's Reference http://www.purl.org/net/TclTkProgRef

David Cuthbert

unread,
Feb 5, 2000, 3:00:00 AM2/5/00
to
Bryan Oakley wrote:
> There must be more to it than what you say. If you truly have a single
> termination condiation as the absolute last statement in a while, that
> will never be more or less buggy than a do ... while statement with the
> termination statement as an argument to "do". Perhaps you aren't rigid
> enough in enforcing that the termination is the very last statement.
> If that is the case, I agree, it can lead to errors in the code.

Unfortunately, we employ falliable humans who, under extreme deadline
pressures, have been known to juggle termination conditions here and there,
even if they were originally coded only at the end of the loop. :-)

> Try it! You'll notice it doesn't ever execute the puts statement. Still,
> it's not perfect, I'll admit. But it does work in your edge case :-)

Ah, no... I just mistyped it when entering it in. You would expect that I
would be smart enough to think to use the cut and paste keys... :-)

Dave

Bogdan Petculescu

unread,
Feb 5, 2000, 3:00:00 AM2/5/00
to

Bogdan Petculescu wrote:

> Ross, you could remain in really standard Tcl with
> an infinite loop simulating a 'repeat ... until' like:
>
> while {1} {
> ...
> if {exit_condition} then {break}
> }
>
> without needing any extra stuff.
>

> Bogdan

Looks like the snowball is on the slope and Ockham's razor
has to be remembered:

Non sunt multiplicanda entia praeter necessitatem.

[William Ockham]

Darren New

unread,
Feb 5, 2000, 3:00:00 AM2/5/00
to
Andreas Kupries wrote:
> > Management of $::errorInfo might be easier if it were maintained as
> > a Tcl list rather than a string, with each level lappending a single
> > element. Any thoughts about that for 9.0?
>
> Oh, interesting idea.

And it would still be a valid list if you put newlines between each element
instead of spaces, so it could still get printed out and be readable without
any extra frobunating. Of course, it'll turn into a proper internal list if
you try to do something listy with it, but I would think that conversion is
more rare.

--
Darren New / Senior Software Architect / IZ, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.

Alexandre Ferrieux

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
Andreas Kupries wrote:
>
> d...@clover.cam.nist.gov (Don Porter) writes:
>
> >Andreas Kupries wrote:
> >>> > set fail [catch {uplevel 1 $body} msg]
> >>> > switch -- $fail {
> >>> > 0 {
> >>> > # ok
> >>> > }
> >... and more
>
> >Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> >> Notice that you need this correction only to get rid of the extra layer
> >> of 'invoked from within "uplevel 1 $body"...' in $errorInfo.
>
> > Not so. Look at the full code again. You need it to properly handle
> > the return codes "break" and "continue".
>
> Correct. I should mention that I just saw that Bryan posted a version
> which I think does not need my big switch to do this. He constructs a
> complete while statement from body and condition and then executes
> that via 'uplevel'. So the 'while' itself will/should take care of
> 'break' and 'continue'.

Yes. Notice that even if you don't eval (uplevel) a just-built loop, the
break and continue exceptions still propagate up the calling stack just
like any other one, hence [while ... { uplevel $script } ] correctly
handles them. Of course, as soon as you explicitly [catch] you need to
be careful to re-throw these !

> > Removing the extra entry in $::errorInfo is a nice finishing touch,
> > but the code Andrea posted didn't even attempt that. It's also more
> > complicated than it first appears, see
>
> > http://www.deja.com/=dnc/getdoc.xp?AN=468519243
>

> > Management of $::errorInfo might be easier if it were maintained as
> > a Tcl list rather than a string, with each level lappending a single
> > element. Any thoughts about that for 9.0?
>
> Oh, interesting idea.

Seconded. What about [info error] ?

-Alex

Alexandre Ferrieux

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
Jeffrey Hobbs wrote:
>
> Joe English wrote:
> >
> > Jeffrey Hobbs <jeffre...@scriptics.com> wrote:
> >
> > >Here's one I have in a little benchmark testing suite for Tcl:
> > >
> > >proc do {body while cond} {
> > > if {[string compare while $while]} {
> > > return -code error "usage: do body while condition"
> > > }
> > > while {1} {
> > > uplevel 1 $body
> > > if {![uplevel 1 [list expr $cond]]} { break }
> > > }
> > >}
> > >
> > >It's similar to some others posted, but this is pedantically the
> > >most correct (could use some more error checking).
> >
> > Hmm...
> >
> > set x 1
> > do {
> > puts "pre: $x"
> > incr x
> > if {$x % 3} { continue }
> > puts "post: $x"
> > } while {$x < 10}
>
> Right, that's due to the lack of "error" checking, which more
> correctly should be called "return code" checking. A correct
> response was posted in the thread.

Jeff, what do you mean ? Looking at the result of the code above, I
can't really blame it as abnormal. Consider: do...while's job in life is
to always do *late* tests, ie you're sure the client call has been run
at least once no matter whether the cond has ever been true. To me, a
natural sequel of this is the one shown by Joe's code: use of {continue}
inside a do...while possibly has this side-effect of not letting the
cond a chance to break the loop soon enough; so what ? Do..while behaves
as
looplabel:
code
check cond
bne looplabel

And in this context 'continue' behaves as

br looplabel

Also, regardless of whether this behavior is accepted or not, don't you
confirm that the propagation of break/continue exceptions works
correctly, without modification of your code ?

I feel I'm missing something enormous. Please forgive me, but please
also help me out !

-Alex

Jeffrey Hobbs

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to Alexandre Ferrieux

The C definition of the do/while continue behavior is in Appendix A,
A9.6 of K&R's book:

continue is equivalent to 'goto contin', and works as such:

do {
....
contin: ;
} while ( ... );

For that reason, my code doesn't have correct continue semantics.
If you took your view where 'contin:' goes to the top of the loop,
then my code would be correct.

Don Porter

unread,
Feb 7, 2000, 3:00:00 AM2/7/00
to
>> > Management of $::errorInfo might be easier if it were maintained as
>> > a Tcl list rather than a string, with each level lappending a single
>> > element. Any thoughts about that for 9.0?

Darren New <dn...@san.rr.com> wrote:
> And it would still be a valid list if you put newlines between each element
> instead of spaces, so it could still get printed out and be readable without
> any extra frobunating.

Perhaps the new variable in which the error stack gets constructed as
a tcl list would be ::tcl::errorStack . Then, ::errorInfo might be
maintained as a backward compatibility interface through the use of
variable traces. Each read of ::errorInfo could return
[join $::tcl::errorStack \n], and each write of ::errorInfo could
trigger a routine which compared $::errorInfo to
[join $::tcl::errorStack \n], determined the new tail which had been
appended, and lappended it to ::tcl::errorStack.

Alexandre Ferrieux

unread,
Feb 8, 2000, 3:00:00 AM2/8/00
to
Jeffrey Hobbs wrote:

>
> Alexandre Ferrieux wrote:
> >
> > Do..while behaves
> > as
> > looplabel:
> > code
> > check cond
> > bne looplabel
> >
> > And in this context 'continue' behaves as
> >
> > br looplabel
> >
> > Also, regardless of whether this behavior is accepted or not, don't you
> > confirm that the propagation of break/continue exceptions works
> > correctly, without modification of your code ?
>
> The C definition of the do/while continue behavior is in Appendix A,
> A9.6 of K&R's book:
>
> continue is equivalent to 'goto contin', and works as such:
>
> do {
> ....
> contin: ;
> } while ( ... );
>
> For that reason, my code doesn't have correct continue semantics.
> If you took your view where 'contin:' goes to the top of the loop,
> then my code would be correct.

Yes, that was my hypothesis. Should get a copy of KnR after all :)
Thanks for clarifying all this !

Now my aim in this subthread was to somewhat attenuate the impression
that "doing new control structs in Tcl is not so easy". Indeed, the
trickery of jump label position just mentioned is the exception; the
seamless propagation of the break and continue 'exceptions' up the call
stack is the rule.

-Alex

Reply all
Reply to author
Forward
0 new messages