gusl: (Default)
[personal profile] gusl
You'd like to write code like:

do {
  A
} while(test)


but your language does not offer do-while (a.k.a do-loop). What do you do?

(a)
A
while(test){
  A
}

(b)
while(TRUE){
  A
  if (!test) break
}

Other?

(no subject)

Date: 2010-02-20 05:53 am (UTC)
From: [identity profile] demarko (from livejournal.com)
(a) mostly because I find it easier to parse

(no subject)

Date: 2010-02-20 03:36 pm (UTC)
gregh1983: (Default)
From: [personal profile] gregh1983
(a), for this reason as well, but I see the point the (b) crowd is making about catching errors.

(no subject)

Date: 2010-02-20 05:58 am (UTC)
From: [identity profile] ernunnos.livejournal.com
B, because it's more resistant to coding errors. If you make a change in the repeated code, you only have to change it in one place, and not two. And although the construct isn't as neat as "do while", "while true break" is understandable to anyone who regularly works in a language that needs it.

(no subject)

Date: 2010-02-20 06:12 am (UTC)
From: [identity profile] gfish.livejournal.com
This. And I'd rather have readability over neatness anyway.

(no subject)

Date: 2010-02-20 06:17 am (UTC)
From: [identity profile] gustavolacerda.livejournal.com
IMHO you're getting both. I find repetitive code to be one of the worst things... (though in some other cases repetition can help readability)

(no subject)

Date: 2010-02-20 06:23 am (UTC)
From: [identity profile] gfish.livejournal.com
Oh, absolutely. I was more referring to using a do-while construction at all. I'd rather just have while, so there are as few types of structures as possible.

(no subject)

Date: 2010-02-20 06:45 am (UTC)
From: [identity profile] gustavolacerda.livejournal.com
Trouble is, "break" can break assumptions people make about post-conditions.

A naive onlooker might say that code running after the loop is evidence that you just refuted TRUE.

(no subject)

Date: 2010-02-20 07:05 am (UTC)
From: [identity profile] en-ki.livejournal.com
I like Ruby's "loop" construct
loop {
  # do stuff
  break if ...;
  # do other stuff
  break if ...;
}
It's an infinite loop if you don't break out of the loop somehow, so in practice you use it whenever you want to do multiple tests, multiple exits, or exits in odd places. It doesn't do anything different from what while(TRUE) does, but it's a clear syntactic marker that you're doing things in this way.

I do wish you could do
do
  stuff()
until CONDITION
as well as
until CONDITION
   stuff()
end
but loop does ok.

(no subject)

Date: 2010-02-20 11:59 am (UTC)
From: [identity profile] gustavolacerda.livejournal.com
until(test) is equivalent to while(!test).

(no subject)

Date: 2010-02-20 02:32 pm (UTC)
From: [identity profile] en-ki.livejournal.com
Yes, what I was illustrating there was the idea you were talking about in your post, running the loop contents once before doing the test. Generally when I want to do that I also want "until", if only to be more English-like. Ruby has

until ...
end

(a while loop with negated test) but not

do ...
until

(a while loop with negated test that unconditionally runs once before the test).

(no subject)

Date: 2010-02-20 06:37 am (UTC)
From: [identity profile] shaktool.livejournal.com
I basically do (b) even in languages that support "do". I kind of forget that "do" even exists.

(no subject)

Date: 2010-02-20 07:14 am (UTC)
From: [identity profile] wjl.livejournal.com
(c)
let fun loop () =
  (A;
   if test then loop () else ())
in
  loop ()
end

(no subject)

Date: 2010-02-20 09:33 am (UTC)
From: [identity profile] demarko (from livejournal.com)
I c wat u did thar

(no subject)

Date: 2010-02-20 05:41 pm (UTC)
From: [identity profile] wjl.livejournal.com
what? it's true! :P

(no subject)

Date: 2010-02-20 03:33 pm (UTC)
From: [identity profile] bhudson.livejournal.com
B unless you're in the not infrequent case where the first iteration is slightly different.

(no subject)

Date: 2010-02-20 07:13 pm (UTC)
From: [identity profile] gwillen.livejournal.com
If I find myself in that case, my instinct is to try to refactor until they're the same. I feel like usually it works.

(no subject)

Date: 2010-02-20 09:10 pm (UTC)
From: [identity profile] bhudson.livejournal.com
I'm thinking of situations like printing a comma-separated list (i.e. implementing perl's "join"). Or summing up a list over a set that has no zero element (or where the extra addition matters to performance).

(no subject)

Date: 2010-02-20 09:45 pm (UTC)
From: [identity profile] gwillen.livejournal.com
Oh yeah, I've always wondered if there might not be a looping construct we could add that would better handle the delimited-list case, since it's not an uncommon thing to have to write.

while (x = next_element()) {
printf(x);
} delimited-by {
printf(", ");
};

or something.

(no subject)

Date: 2010-02-20 10:00 pm (UTC)
From: [identity profile] wjl.livejournal.com
i think i tried to come up with a solid higher-order function interface for this once, but i don't remember it being very satisfying.. i think i had it taking three pieces of code: one for the beginning, one for the end, and one for the in-betweens. but i guess you really don't need the beginning code or the end code, since you could just put it outside the loop..

(no subject)

Date: 2010-02-20 09:47 pm (UTC)
From: [identity profile] gustavolacerda.livejournal.com
For stuff like that, my instinct is to use a Reduce in which the two-argument function simply inserts a comma between the two arguments.

(no subject)

Date: 2010-02-24 04:27 pm (UTC)
From: [identity profile] raflacerda.livejournal.com
for(i=0;i<1;){
A
if(test)i++;
}

(no subject)

Date: 2010-02-24 05:24 pm (UTC)
From: [identity profile] gustavolacerda.livejournal.com
This is the same as (b), except for introducing a variable that is never used.

(no subject)

Date: 2010-02-24 11:23 pm (UTC)
From: [identity profile] gustavolacerda.livejournal.com
I guess there is one advantage: you're not using break...

February 2020

S M T W T F S
      1
2345678
9101112131415
16171819202122
23242526272829

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags