## [XP] Re: New Article: More Hassling with Haskell

Expand Messages
• ... wrote: -snip- ... Let s agree the defect is due to an incorrect termination condition. What puzzles me is that you keep saying it matters
Message 1 of 33 , Nov 5, 2006
--- In extremeprogramming@yahoogroups.com, Ron Jeffries
<ronjeffries@...> wrote:
-snip-
> > afaict the fact that the program used recursion is incidental, I
> > imagine we can have the same error using a for loop - the mistake was
> > a mistake in understanding the problem.
>
> Hardly. I fancy I understand Bowling scoring rather well now, having
> programmed it so many times. And I'd like to see you code up that
> same error with a for loop, since the defect is due, precisely, to
> an erroneous recursion termination condition which must be hard to
> spot, since so many keen eyes, including our own, didn't spot it.

Let's agree the defect is due to an incorrect termination condition.

What puzzles me is that you keep saying it matters that we are
terminating a recursion rather than an iteration - it does not.

What matters is that we take account of the difference in scoring
rules between the 10th and previous frames, and for that we need a
frame count of some kind.

This program uses iteration (I even used a for loop just in case you
were feeling pernickety) and has the same error as those recursive
programs.

int score(int[] pins){
var total = 0;
var i = 0;

for (var j = 0; j<pins.length; j++){

if (i+3==pins.length) {
total += pins[i] + pins[i+1] + pins[i+2];
i += 2;
}
else if (i+2<pins.length && pins[i] == 10) {
total += pins[i] + pins[i+1] + pins[i+2];
i ++;
}
else if (i+2<pins.length && pins[i]+pins[i+1] == 10) {
total += pins[i] + pins[i+1] + pins[i+2];
i += 2;
}
else if (i+1<pins.length) {
total += pins[i] + pins[i+1];
i += 2;
}
}
}

void main(String[] args){
let int[][] tests = [
[0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0],
[3,3, 3,3, 3,3, 3,3, 3,3, 3,3, 3,3, 3,3, 3,3, 3,3],
[4,6, 3,5, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0],
[4,6, 5,3, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0],
[10, 5,3, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0],
[0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 10, 5,3],
[0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 4,6, 5],
[10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10],
[10, 4,6, 10, 4,6, 10, 4,6, 10, 4,6, 10, 4,6, 10],
[0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 10, 2,3],
[0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 0,0, 10, 2,3]
];

for(each:tests) println( score(each) );
}

>nicec --sourcepath .. -a t.jar tenpin
nice.lang: parsing
tenpin: parsing
tenpin: typechecking
tenpin: generating code
tenpin: writing in archive
nice.lang: writing in archive

>java -jar t.jar
0
60
21
23
26
18
15
300
200
15
15
• ... I m reading it via gmail, and I just decided to go back and look at your message via show original message , which shows the message without any
Message 33 of 33 , Nov 20, 2006
On 11/20/06, Donald Roby <droby@...> wrote:
>
> Buddha Buck wrote:
> >
> > For what it's worth, it looks OK to me (i.e., it doesn't look weirdly
> > misformatted), but I don't do that much Haskell, so I might be missing
> > something. The only unusual formatting I saw was one line looked as if
> it
> > had been word-wrapped. It certainly didn't look like I would expect
> > code-interpreted-as-HTML would have looked. If course, as a
> > I get this list from yagoogroups in "text email", not "HTML email". That
> > might have something to do with it.
> >
>
> This one wasn't as bad as the previous one, basically because there was
> less line wrap due to less long lines. But at least as viewed through
> Thunderbird and via the group web interface, it pretty much removed
> indentation. And indentation is sometimes important in Haskell ... even
> more in Python. Maybe as you're reading with a text-based system, the
> indentation was intact.

I'm reading it via gmail, and I just decided to go back and look at your
message via "show original message", which shows the message without any
formatting.

When the original message is viewed, in the "code" section (which I saw as
raw tags, not as formatted stuff), I can see that everything except the
first "module Bowling where" line is indented (at least) two spaced. In the
formatted version, that is basically invisible, but I think that has more to
do with gmail defaulting to a proportional font so consecutive spaces are
nearly invisible.

The rest of the indenting looks odd to me, but that may be due to Haskell
formatting conventions than anything. The definition of framescores(x:xs)
has the "=" on the second line under the xs. And the definition of
bonus(x:xs) has the "then" and "else" clauses lined up with the "10" in the
conditional. No other statement or definition is written across two lines
(I'm considering framescores([]) and framescores(x:xs) to be two
defintions).

> Thought of that after I saw the effect. I use "tags" in email
> frequently, but don't actually expect them to affect the display.

I don't think it did on my end.

If the server allows through arbitrary markup and lets it remain as
> markup, it's subject to lots of abuse, so even though it would help in
> this instance, I hope they don't do that.

The server *should* allow it through. How the message is formatted should
ultimately be a result of my mailreader, not what an intermediary chooses to
do with it. Part of my "traditionalist" leanings is that I don't want
yahoogroups (or Google, for that matter) making arbitrary changes to my
email as it goes through.

[Non-text portions of this message have been removed]
Your message has been successfully submitted and would be delivered to recipients shortly.