Comments on: any with foldr

By: Matt

Matt — Tue, 24 Feb 2009 22:12:19 +0000

Agreed that there is redundancy that helps humans to understand, but there is redundancy that makes things harder to understand, e.g. Java’s painful constructs like:

Map map = new HashMap

The thing I like about type inference is that I get the option, as a programmer, to give the types when I think it would be most helpful for others reading the program. At the least, in Haskell, it certainly makes a lot of sense (and I believe is a widely adopted best practice?) to annotate at least the top-level functions of a program with explicit types. Something that would help with Haskell is an editor/IDE with the feature that you can highlight any subexpression, and it would show you the inferred type of that subexpression (I don’t know of any, though.)

By: Anonymous

Anonymous — Sat, 24 Jan 2009 22:35:28 +0000

What about this?

myAny :: (a -> Bool) -> [a] -> Bool
myAny f xs = foldr step False xs
where step x acc = acc || f x

By: Elliotte Rusty Harold

Elliotte Rusty Harold — Sat, 24 Jan 2009 14:45:03 +0000

Yep, it's buggy. Here's a fixed version:

myAny :: (a -> Bool) -> [a] -> Bool
myAny f [] = False
myAny f (x:xs) = foldr step (f x) xs
     where step x acc = acc || f x

By: Michael Day

Michael Day — Sat, 24 Jan 2009 04:01:57 +0000

Right, myAny does not need to do pattern matching on the list, it can just pass it to foldr.
I agree regarding type inference: explicit type declarations give the programmer a chance to state their intent and act as documentation for those who come after. Type inference for local variables is a big time saver though, especially compared to the classic Java pattern:StupidFactory stupidFactory = new StupidFactory();

By: Anonymous

Anonymous — Sat, 24 Jan 2009 01:05:55 +0000

I haven’t run it, but I’m pretty sure your definition has a bug: it ignores the first element of the list.