4 ms·

I don't wanna be "that guy", but this seems to just be the the list monad.

drostie 9y ago
You're not wrong, if the only verb is `c.expand()`. In Haskell you would write: -- omitting the definitions as trivial... cmdline (Suite box (Compiler cmd _ out_opt) (Test binary sources)) = intercalate " " [cmd, sources, out_opt, binary] testSuites = [Suite srvr comp test | srvr <- [box1, box2, box3, box4], comp <- [gcc, clang, msvc], test <- [frobnicate, loadtest, end2end], not (binary test == "loadtest" && ram srvr < 8)] (Note that Haskell lets you specify what `==` means so probably the above should say `test == loadtest` more directly...) If there are other verbs then it might not be 100% equivalent. For example one might want a sort of "Non-uniform random choice monad," let's say a monad of "Choosers", which will quickly generate a random candidate test suite. If you wanted to support both, you'd want to quickly define: class Monad m => MChoice m where choose :: [x] -> m x invalid :: m x invalid = choose [] mfilter :: Bool -> m () mfilter True = return () mfilter False = invalid instance MChoice [] where choose = id Then you can say, testSuites :: MChoice m => m TestSuite testSuites = do srvr <- choose [box1, box2, box3, box4] comp <- choose [gcc, clang, msvc] test <- choose [frobnicate, loadtest, end2end] mfilter . not $ test == loadtest && ram srvr < 8 return $ Suite srvr comp test In this respect maybe Cartesian programming represents a generalization of the list monad.
pron 9y ago
I think someone once proved that all programming languages (or just about) are equivalent in their expressiveness, and given that similar problems arise in all paradigms, it is not surprising that all paradigms have their own names for similar things. Just as monads and continuations are two different ways to express similar computational notions, it would not be surprising if there were others. None of these is more fundamental or "real" than the others. They are simply different ways to formally model an abstract concept.

You're not wrong, if the only verb is `c.expand()`. In Haskell you would write: -- omitting the definitions as trivial... cmdline (Suite box (Compiler cmd _ out_opt) (Test binary sources)) = intercalate " " [cmd, sources, out_opt, binary] testSuites = [Suite srvr comp test | srvr <- [box1, box2, box3, box4], comp <- [gcc, clang, msvc], test <- [frobnicate, loadtest, end2end], not (binary test == "loadtest" && ram srvr < 8)] (Note that Haskell lets you specify what `==` means so probably the above should say `test == loadtest` more directly...) If there are other verbs then it might not be 100% equivalent. For example one might want a sort of "Non-uniform random choice monad," let's say a monad of "Choosers", which will quickly generate a random candidate test suite. If you wanted to support both, you'd want to quickly define: class Monad m => MChoice m where choose :: [x] -> m x invalid :: m x invalid = choose [] mfilter :: Bool -> m () mfilter True = return () mfilter False = invalid instance MChoice [] where choose = id Then you can say, testSuites :: MChoice m => m TestSuite testSuites = do srvr <- choose [box1, box2, box3, box4] comp <- choose [gcc, clang, msvc] test <- choose [frobnicate, loadtest, end2end] mfilter . not $ test == loadtest && ram srvr < 8 return $ Suite srvr comp test In this respect maybe Cartesian programming represents a generalization of the list monad.

pron 9y ago

I think someone once proved that all programming languages (or just about) are equivalent in their expressiveness, and given that similar problems arise in all paradigms, it is not surprising that all paradigms have their own names for similar things. Just as monads and continuations are two different ways to express similar computational notions, it would not be surprising if there were others. None of these is more fundamental or "real" than the others. They are simply different ways to formally model an abstract concept.