[Haskell-cafe] (no subject)

[staafmeister]

Thank you for the reply.


Thomas ten Cate wrote:
> 
> Although you most certainly can use a State monad, in most problems
> this isn't necessary. Most algorithms that you need to solve
> programming contest problems can be written in a purely functional
> style, so you can limit monadic code to just a few helper functions.
> 

Yes I know but there are a lot of problems requiring O(1) array updates
so then you are stuck with IO again


Thomas ten Cate wrote:
> 
> For example, this reads input in the style you mention (assuming the
> strings don't contain whitespace):
> 
>> import Control.Monad
>>
>> answer = id
>>
>> parse [] = []
>> parse (s:p:r) = (s, (read p) :: Int) : parse r
>>
>> run = getLine >> getLine >>= putStrLn . show . answer . parse . words
>>
>> main = flip replicateM_ run =<< readLn
> 
> The answer function would be a pure function that computes the answer
> for a particular run. This main function is reusable for all problems
> with many runs.
> 
> Observe that the number of edges (e), provided as a convenience for
> memory allocation in many other languages, is not even necessary in
> Haskell :)
> 

Yes you're main is short. But how would you do it elegantly if 
instead of line breaks and spaces one would have only spaces.
Every thing on one big line. My C code would not mind one bit.


Thomas ten Cate wrote:
> 
> (If anyone knows a better way than explicit recursion to map over a
> list, two elements at a time, or zip its even elements with its odd
> elements, I'd love to hear! I can imagine a convoluted fold with a
> boolean in its state, but it's ugly.)
> 

Yes I missed such a function in a couple of problems I wanted to solve.
I would expect a generic function
groupN::Int -> [a] -> [[a]]
that groups a list into groups of N

Best,
Gerben
-- 
View this message in context: http://www.nabble.com/%28no-subject%29-tp25088427p25094244.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.