On Thu, 2009-07-02 at 15:43 +0400, Bulat Ziganshin wrote:

Hello Maciej,

Thursday, July 2, 2009, 3:31:59 PM, you wrote:

...

class (Monad m, Monoid v) => MonadInput v m where -- | Gets an element from input (line of text [with \n], 4096 bytes, -- or something like that). mzero on end getChunk :: m v class (Monad m, Monoid v) => MonadOutput v m where -- | Puts an element putChunk :: v -> m ()

how about interact function?

Well. As far as I know there is no way of using it with network. Additionally there is hard to put monadic code in it: myFunc :: (MonadInput i, MonadOutput o) => (String -> m a) -> MyMonad i o m [a] If m == IO - which may be a case in normal code it requires unsafePerformIO with all it's problems. In testing I can use pipes and Identity simplifying the whole testing - allowing user to use it's own monads. The other problem is that the order sometimes matters. Consider: main = interact (\x -> "What's your name?\n" ++ "Hello:\n" ++ x) For human being it is annoying but sometimes it is for example against RFC. Regards

On Thu, Jul 2, 2009 at 1:18 PM, Luke Palmer wrote:

I used to approach problems by designing a monad for my whole program, using an appropriate stack of transformers. I suspect such an approach led to the claim that "monads are not appropriate for large software systems" in a popular paper a few months ago.

Link please! I googled but I couldn't find it :( I'd like to find out what you and the authors have learned about the inappropriateness of monads for large software systems. Thanks, Jason

On Thu, 2009-07-02 at 14:18 -0600, Luke Palmer wrote:

On Thu, Jul 2, 2009 at 5:31 AM, Maciej Piechotka wrote: 2. I find writing monad transformers annoying. Additionally if package defines transformer A and another transformer B they need to be connected 'by hand'.

You have not given any concrete problems or examples, so it's hard for me to comment. But at first glance, I would conjecture that you are relying too heavily on monads and sequential thinking.

Consider what your code would look like without a single monad. Obviously you cannot talk to the network without IO, but your program can still be modeled purely, and then toss in IO at the last second to tie it to the network. This model may be difficult for you because it requires your brain to be rewired; feel free to mail this list with concrete modeling problems and we will help you out.

As for the pure model, throw away Reader, Writer, State -- everything, and just use pure functions. Then add monads back in at small scopes when they clean things up.

AFAIU you comment the 2de point only. I look at this moment from library, not program point of view. So consider the library IOMonad which defined some MonadInput v m monad. Then you have NNTP library which has NntpT m monad. Each of them defines appropriate stack such as that NntpT (State s) is instance of MonadState. But if there is NntpT MyInput, where MyInput isinstance of MonadInput, is not MonadInput. To do it with current approach the libraries would have to be interlinked. Also it is quite boring to include for all monad instance ... => ... where f1 = lift f1 f2 = lift f2 ...

I used to approach problems by designing a monad for my whole program, using an appropriate stack of transformers.

I thought about others which might have want to use my monads in their functions...

I suspect such an approach led to the claim that "monads are not appropriate for large software systems" in a popular paper a few months ago.

I'd appreciate the link - google find nothing. I fall in love in Haskell about a week or two ago and I fall in love just after I started learning it ;)

As I have gained more experience, I found that this is the wrong way to go about using them. Now my primary use of monads is within the scope of a single function, to tie together the helper functions in the where clause.

Luke

Regards

Gwern Branwen wrote: ...

" Ultimately, the problem with Haskell and ML for our purposes is that the brightest and most aggressive programmers in those languages, using the most aggressive optimization techniques known to the research community, remain unable to write systems codes that compete reasonably with C or C++. The most successful attempt to date is probably the FoxNet TCP/IP protocol stack, which incurred a 10x increase in system load and a 40x penalty in accessing external memory relative to a conventional (and less aggressively optimized) C implemenation. [ 4 ,6 ]"

http://www.bitc-lang.org/docs/bitc/bitc-origins.html

Interesting paper. Putting these remarks in context, in case anyone takes them as a current critique of Haskell, they are apparently about ten years out-of-date and apply to this SML program http://www.cs.cmu.edu/~fox/foxnet.html I wonder what would happen if the program was ported and benchmarked in a recent version of GHC. Richard.