ignore this one

[alexr_rwx]

From Paulson's ML for the Working Programmer:

The product of a list of integers can be computed like this:

fun prod ns = if null ns then 1 else (hd ns) * (prod (tl ns));

If you prefer this version of prod, you might as well give up ML for Lisp. For added clarity, Lisp primitives have names like CAR and CDR. Normal people find pattern-matching more readable than hd and tl.

*laughs* I guess I'd better give up ML for LISP, then, because that's exactly how I'd do it. I'm sure that ML is, uh, lovely when you get to know it (perhaps analogous to "I'm sure that deep down inside, he's a really nice guy..."), but it just feels pretentious, as a language. The Paulson text really doesn't help.

And it's not that it's totally debilitating, trying to code in it, anymore... it's just that it's incredibly slow going, and the documentation sucks. And this is me whining that I could whip out the cs4240 project in LISP in like a quarter of the time, if that.

Nyip, off to go do things...

Comments

[sstrickl.livejournal.com]

But why not:

fun prod [] = 1
  | prod x :: xs = x * (prod xs)

I think that's the point of that remark -- if you're going to be using ML, you might as well get the benefit of the built-in pattern matching! :)

[sstrickl.livejournal.com]

You could make it even cleaner and use nice formatting:

fun prod []      = 1
  | prod x :: xs = x * (prod xs)

Of course, I'd probably rather just use:

fun prod xs = foldl op* 1 xs

if I was going to define prod as a function instead of just inlining the fold :)

[sstrickl.livejournal.com]

The benefit of the latter being that it's iterative since foldl is written in a tail recursive style whereas I'd have to worry about writing an accumulator-style one for prod.

I've made too many comments already -- I should be more patient when writing them, then I wouldn't think of things after the fact!

[sstrickl.livejournal.com]

Or:

val prod = foldl op* 1

Okay, now I'm geeking way too much on the expense of your journal.

[falun.livejournal.com]

that's ok... geeking _is_ a spectator sport

[sstrickl.livejournal.com]

And now I reread the quote and see "Normal people find pattern-matching more readable than hd and tl." Oops, I wouldn't have even posted what I did if I'd seen that, though I am still curious as to why you prefer the other :)

I swear I'm not an idiot!

[falun.livejournal.com]

he is, really... i mean... would I ever [intentionally] mislead you? I didn't think so

[lindseykuper]

Normal people find pattern-matching more readable than hd and tl.

I read this and was all, "What?! What normal people would those be?" But then I remembered that this was ML pattern-matching, and not Perl or something.

And yeah, Paulson's example might look more like Lisp than ML, but that doesn't mean there wouldn't be other ways to do it in Lisp. Tail-recursive ways, for instance.

[oniugnip.livejournal.com]

*laughs* If you push on the idea a little harder, most "normal people" probably don't care which mostly-functional language any of us happen to like, totally unrelated to whether it's got strong typechecking or pattern-matching or even a nice garbage collector.

("Eh? What's all that crap on your screen? ...")