Hi,
The classical Hamming problem have the following solution in Haskell :
*** BEGIN SNAP
-- hamming.hs
-- Merges two infinite lists
merge :: (Ord a) = [a] - [a] - [a]
merge (x:xs)(y:ys)
| x == y= x : merge xs ys
| x y= x : merge xs (y:ys)
| otherwise = y : merge (x:xs) ys
--
'hamming', in your code, is a top-level definition. When used three
times inside its own definition, it's the same variable being used
three times. You don't recompute a variable value in order to reuse
it.
As an example, if you do
foo :: [Integer]
foo = [1,2,3] + [4,5]
bar = foo ++ foo ++ foo
It doesn't have to be a top level definition, it works anyway.
-- Lennart
Bruno Abdon wrote:
'hamming', in your code, is a top-level definition. When used three
times inside its own definition, it's the same variable being used
three times. You don't recompute a variable value in order to
Notice that 'hamming' *is* a list of integers, not a function to produce them:
hamming :: [Integer]
Thus, the magic here is that you can define this list as a value, without
having to actually evaluate any element until it's needed, either by direct
reference from another function, or
Thank you,
I understand the point.
But I can't help thinking that the distinction between being a list of
integers and being a function that returns a list of integers (without
arguments) is not always clear in FP ... since there is not really such a
thing as returning a value in declarative
On Monday 24 January 2005 21:47, Francis Girard wrote:
But I can't help thinking that the distinction between being a list of
integers and being a function that returns a list of integers (without
arguments) is not always clear in FP ... since there is not really such a
thing as returning a
