The previous post used a one-liner to solve the problem, using a list comprehension. Trying different limits meant editing the number in the middle of the line and entering again. That’s really the only thing you can easily do in the GHCi interactive environment—any functions or more complex code needs to be in an actual source file. At least GHCi can load your source file and then let you interact with the functions defined in it.
So, here’s a function which takes the max in the problem statement. To completely generalize, it also takes the list of factors as a parameter. After all, the original code was starting to look repetitive on the handling of the two hard-coded factors.
divisors ∷ [Int] → Int → Int divisors factors max = sum [x | x ← [1‥max], factor factors x] factor factors n = any (λx → n `mod` x ≡ 0) factors -- swap out these alternatives by leaving exactly one un-commented -- or [b | x ← factors, let b= n `mod` x ≡ 0] -- or [True | x ← factors, n `mod` x ≡ 0]
As well as using recursion, the list comprehension syntax offers a way to write what would be a loop in imperative languages. The generator portion of the construct,
x ← [1‥max], is like a foreach loop, though it is not limited to using one generator. The things after the vertical bar can include generators, constraint tests, and named values to use in other things. However, it doesn’t seem directly suited to using the factors list directly as a generator with other tests — the built-in meaning is an AND between constraints, not an OR. So, push that down to another function, top-down style. That is, sum all the numbers up to max where the number passes the test of function factor.
I knew that there are logical functions that apply across all elements in a list, but didn’t recall how they were named. Looking through the library, I found
any first, which is even more suitable. It reads more clearly to indicate the intent, rather than having to know that a multi-input OR can be used in that manner. But, it needs the test packaged as a separate function. Here I did that in-line as a lambda.
Since the point of this exercise is to work with list comprehensions, I tried it using the
or function, too. Mapping the list of factors to a list of True/False is done within the list comprehension syntax, doesn’t need extra parens, but isn’t really clearer: it trades the lambda for a
But, there is no reason to populate all the False entries. The natural use of the filtering clause is to reject elements that don’t meet the criteria. So, accept the ones that would give True, rather than mapping to True. A form similar to this would be useful if I wanted to list the ones that fit, rather than just finding out if any fit.
Interestingly, the first form can be written without using a lambda expression. Nice normal function composition doesn’t work out because the argument is deep in the center rather than last, but section syntax lets you use either the left or right argument in an operator. The section syntax uses parenthesis, and you end up needing parens around the whole thing because the infix ∘ has a lower precedence than function application.
factor factors n = any ((0≡)∘(n `mod`)) factors