On Wed, 13 Sep 2006, Donald Bruce Stewart wrote:

lemmih:

...

On 9/13/06, Tim Newsham wrote:

...

I was rewriting some non-haskell code in haskell and came up with this construct:

foreach l f = mapM_ f l

main = do args <- getArgs foreach args (\arg -> do foreach [1..3] (\n -> do putStrLn ((show n) ++ ") " ++ arg) ) )

which is reminiscent of foreach in other languages. Seems fairly useful and I was wondering how hard it would be to add some syntactic sugar to the "do" construct to make it a little prettier (ie. not require the parenthesis, binding and nested do, as:

main = do args <- getArgs foreach args arg foreach [1..3] n putStrLn ((show n) ++ ") " ++ arg)

would this type of transformation be possible with template haskell or does this need stronger support from the parser to pull off?

How about:

main = do args <- getArgs flip mapM_ args $ \arg -> flip mapM_ [1..3] $ \n -> putStrLn $ show n ++ ") " ++ arg

Which is, with current Control.Monad:

main = do args <- getArgs forM_ args $ \arg -> forM_ [1..3] $ \n -> putStrLn $ show n ++ ") " ++ arg

I think Tim is looking for an if-then-else "real syntax" feel to his `foreach' though. I.e. TH or some small preprocessor.

Adding sugar or using Template Haskell for such a simple task is a bit unreasonable. I think Tim should use mapM a little bit and then he will probably need no longer a special syntax. If you want more sugar, what about the list monad? main = do args <- getArgs sequence_ $ do arg <- args n <- [1..3] return (putStrLn $ show n ++ ") " ++ arg) or main = do args <- getArgs sequence_ $ liftM2 (\arg n -> putStrLn $ show n ++ ") " ++ arg) args [1..3]

On Wed, 13 Sep 2006, Bulat Ziganshin wrote:

Wednesday, September 13, 2006, 1:12:35 PM, you wrote:

...

Adding sugar or using Template Haskell for such a simple task is a bit unreasonable. I think Tim should use mapM a little bit and then he will probably need no longer a special syntax.

i disagree. lack of good syntax makes imperative programming in Haskell less convenient. i want to have such syntax in order to make Haskell great imperative language:

sum <- new 0 arr <- new Array[1..3] for i in [1..3] do sum += i arr[i] := sum for i in [1..3] while arr[i]<2 do print arr[i]

let arr = scanl1 (+) [1..3] in mapM_ print (takeWhile (<2) arr)

Hello Michael, Thursday, September 14, 2006, 12:44:37 AM, you wrote:

Or, what about using ListT to combine it with IO, eliminating the need for two separate `do' blocks?

according to my experience, in most cases we need two do blocks just because outer one contains more code after inner one finishes up -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Udo, Wednesday, September 13, 2006, 12:53:38 PM, you wrote:

...

main = do args <- getArgs flip mapM_ args $ \arg -> flip mapM_ [1..3] $ \n -> putStrLn $ show n ++ ") " ++ arg

Or even:

main = do args <- getArgs putStr $ unlines [ show n ++ ") " ++ arg | arg <- args, n <- [1..3] ]

I'm really at a loss trying to understand why some people seem to like the imperative style. In fact, most of the time, the strings in the code above are better replaced by Doc from Text.PrettyPrint.

because REAL code is somewhat larger than examples. try to rewrite the following: directory_blocks <- (`mapM` splitBy (opt_group_dir command) files_to_archive) ( \filesInOneDirectory -> do datablocks <- (`mapM` splitToSolidBlocks filesInOneDirectory) ( \filesInOneDataBlock -> do let compressor = map (freearcLimitDictionary$ clipToMaxInt totalBytes) (data_compressor filesInOneDataBlock) totalBytes = sum$ map (fiSize.cfFileInfo) filesInOneDataBlock copy_solid_block = isWholeSolidBlock filesInOneDataBlock writeBlock pipe DATA_BLOCK compressor copy_solid_block $ do dir <- if copy_solid_block then do sendP pipe (CopySolidBlock filesInOneDataBlock) return$ map fileWithCRC filesInOneDataBlock else if (compressor==[aFAKE_COMPRESSION]) then do sendP pipe (FakeFiles filesInOneDataBlock) return$ map (FileWithCRC 0 . cfFileInfo) filesInOneDataBlock else do mapMaybeM (read_file command bufOps decompress_pipe) filesInOneDataBlock processDir dir return dir ) blocks_info <- replicateM (length datablocks) (getP backdoor) arcpos <- archiveGetPos archive writeControlBlock DIR_BLOCK dir_compressor $ do archiveWriteDir blocks_info arcpos receiveBuf sendBuf ) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Bulat Ziganshin wrote:

because REAL code is somewhat larger than examples. try to rewrite the following:

directory_blocks <- (`mapM` splitBy (opt_group_dir command) files_to_archive) ( \filesInOneDirectory -> do datablocks <- (`mapM` splitToSolidBlocks filesInOneDirectory) ( \filesInOneDataBlock -> do [...]

This particular snippet contains too many undefined identifiers to be rewritten effectively, but I'm very sure that the whole program can be restructured to great effect. Maybe by designing a "binary-block"-combinator language which calculates padding bytes and length headers automatically and fiddles out scheduling for fast writing to a pipe, something like that. Eventually, a binary parser combinator library which can read single bit flags and things is a must here. It may even be possible to combine the two providing a bijection between abstract file tree, "tar"-ed blocks and compressed binary file. Separate your concerns, ban IO as much as possible and any function that takes more than 15 lines is a wart. I admit that real world applications are not a good exercise to practice functional programming, but once acquired, advanced functional tactics prove very powerful. An example might be WASH/CGI which successfully abstracts session state over HTTP, a problem where Perl-Scripts are doomed and all kind of imperative buzz like JavaBeans and so on have been invented but somewhat fail to solve it for non-trivial cases. Regards, afpelmus

Brandon Moore wrote:

Couldn't '\' delimit a subexpression, as parentheses do? Would there be any ambiguity in accepting code like State \s -> (s, s) instead of requiring State $ \s -> (s, s), or taking

main = do args <- getArgs foreach args \arg -> do foreach [1..3] \n -> do putStrLn ((show n) ++ ") " ++ arg

It would be a bit odd to have a kind of grouping the always starts explicitly and ends implicitly, but other than that it seems pretty handy, harmless, and natural (I know I've tried to write this sort of thing often enough)

Sounds like an extremely good idea to me. Ben

Bulat Ziganshin wrote:

we can also develop some ideas that will allow user to extend language with imperative-friendly features. first, the problem is that Haskell requires to exactly specify order of evaluation.

...

second, we need to be able to define new keywords together with using layout statements in our constructs:

and last problem is what code to generate for break/continue (goto? :) operation I realize Mr. Ziganshin has much more experience with Haskell than I (I only became aware of Haskell in the last year and I'm still struggling with the more advanced corners of the language.) But I have to respectfully disagree with these suggestions. At no point have I wished

... that Haskell adopt more from the imperative programming world! Others have already shown how "foreach" can be written in a functional manner. I think it's more important that we (the new members of the Haskell community) learn the language rather than make the language more familiar to imperative programmers. My exposure to Haskell (in its current form) motivated me to attend this year's ICFP conference. (I'm looking forward to attending the Haskell Workshop this Sunday.) -- Rich