4 ms·
For printf debugging you can use the "trace" function from Debug.Trace. A "first n files that don't exist" function could be something like: nexist :: Int ->
by danidiaz 14y ago
For printf debugging you can use the "trace" function from Debug.Trace.
A "first n files that don't exist" function could be something like:
nexist :: Int -> [FilePath] -> IO [FilePath]
nexist n l = take n . map fst . filter (not.snd) . zip l <$> mapM doesFileExist l
- Maro 14y agoI hope you don't take offense at what I'm about to say, but the code snippet you provided is not maintainable in the sense of not being readable. It sacrifices maintainability for cleverness. As someone above pointed out, sometimes it's better to write 5 lines instead of 2 lines. We don't write code primarily for the compiler, if we would then we wouldn't be having this discussion because the compiler doesn't mind spaghetti. We write code for the next guy who will try to read, understand and modify the code. As an experienced programmer I can tell you, but you probably know anyway, that in all languages you can write very concise but completely incomprehensible snippets which even you won't understand in 2 weeks.
- mifrai 14y agoHonestly, I don't think danidiaz was trying to be clever so much as not knowing about the existence of filterM. A good chunk of the code was just an implementation of it: filterM' f xs = map fst . filter snd . zip xs <$> mapM f xs So, given filterM, the code would have looked like nexist n xs = take n <$> filterM (fmap not . doesFileExist) xs Which doesn't look clever at all and it's fairly easy to understand.