I think my brain just exploded

List comprehensions are cool eh! They are available as well for ocaml as a Camlp4 extension (the [ a .. b ] notation is not available however, so one has to define range):

# #directory “+camlp4″;;
# #load “camlp4o.cma”;;
Camlp4 Parsing version 3.10.0

# #load “Camlp4Parsers/Camlp4ListComprehension.cmo”;;
# let rec range a b = if a > b then [] else a :: range (a+1) b;;
val range : int -> int -> int list =
# let f n = [ (x,y,z) |
x <- range 1 n;
y <- range (x+1) n;
z (int * int * int) list =
# f 20;;
- : (int * int * int) list =
[(3, 4, 5); (5, 12, 13); (6, 8, 10); (8, 15, 17); (9, 12, 15); (12, 16, 20)]

I think haskell is definately a nicer language than ocaml. Doing stuff in ocaml often involves some rather ugly looking code, while haskell always seems to offer a consistent and elegant way to do anything. Just little things like completely removing the distinction between an operator and a function. In ocaml you can use an operator as a function, but you can’t use a function as an operator. Haskell lets you go both ways. And of course . and $ let you do away with the excessive parens that ocaml code requires. I also find doing imperative code in haskell much nicer than ocaml’s semicolon hell.

Of course, ocaml has a much better implimentation than haskell does. GHC is the best you get with haskell (pretty much your only option really considering how many extensions and stuff are GHC only) and it can take a really long time to compile code at times. Ocaml has a fantastic implimentation, bytecode and native compilers that are very fast, lex and yacc, debugger, profiler, proper interactive mode, its all there. But GHCi is a lot better now than it was, and there’s on-going work to make ghc have fewer corner cases that make it grind to a halt. If alex, happy, hat and haddock became offical tools that came with GHC so you didn’t have to worry about 4 seperate possible version mismatches it would certainly make things nicer too.

In passing, let me mention that the monadic version which looks quite similar too (even more so with the do notation not shown here):

let f n =
range 1 n >>= (fun x ->
range (x+1) n >>= (fun y ->
range (y+1) n >>= (fun z ->
if x * x + y * y = z * z then return(x,y,z) else [] )))

(the >>= and return are the standard monadic operators on lists — see http://enfranchisedmind.com/blog/2007/08/06/a-monad-tutorial-for-ocaml/).

Here is a slight tweak of your haskell code to make it generate ALL of the pythagorean triples, in order of hypotenuse length:

pythagoreanTriples :: [(Int, Int, Int)]
pythagoreanTriples = [(a, b, c) | c <- [1..], b <- [1..c-1], a <- [1..b-1], a^2 + b^2 == c^2]

Prelude> take 5 pythagoreanTriples
[(3,4,5),(6,8,10),(5,12,13),(9,12,15),(8,15,17)]

Oh man – spoilers for Problem 9 of Project Euler or what. (-: I’m working on that one at the moment, but using Erlang.

for parselmouths:

filter(lambda (x, y, z): x*x + y*y == z*z, [(a, b, c) for a in range (1, n+1) for b in range (a, n+1) for c in range(b, n+1)])

obviously, the haskell and python versions are idea-wise isomorphic.

and here’s a kind of O(n^2) version . the range for the multiplying factor (mu) is off the top of my head, and is there to take the output from the p-q stuff (eg (3,4,5)) and get the derived triplets (eg (6,8,10) and (12,16,20)). i say “kind of” O(n^2) because the generation of unique triplets is O(n^2) at minimum, and multiplying each of the integers in the triplet to get all the derived triplets is an additional operation. i don’t have the upper bound for the multiplying factor, though if it can be proved that such a bound exists and is independent of n, the algorithm would become strictly — as opposed to “kind of” — O(n^2)

filter(lambda (a, b, c): max(a, b, c) <= n, [(p*q*mu, ((p**2 - q**2)/2)*mu, ((p**2 + q**2)/2)*mu) for q in range(1,n,2) for p in range(q+2,n,2) for mu in range(1, 5)])