So to summarize: the hard part is laziness. I concur, and I have absolutely no plans to consider making BitC a lazy language.
Another issue is that we might need to move to rank-2 polymorphism, which is a jump that I would prefer not to take. On Tue, 2008-03-25 at 13:59 -0500, James Graves wrote: > I am not a Haskell expert, but I do have several comments. > > 1) Monads have been added onto other languages. Particularly functional > languages like Ocaml. So it may be possible to add if later if desired. > Though it can be an advantage getting this in early the programming > language lifecycle, so it becomes standard. > > 2) I didn't think the coding style of a typical Haskell program matched > the style encouraged by BitC. I'm talking about stuff like currying, > which is commonly used. > > 3) I'd think that translating lazy and pure code to strict would be > difficult in many cases. More like writing completely new code. > > 4) Monads are useful when it comes to analysis of program code, formally > or informally. Their use, especially in Haskell, forces the programmer > to directly and explicitly reason about mutable state. It is "all right > there" in terms of seeing who is changing what. There are no hidden > little side effects in an innocuous function named > "retrieve_calculated_result", for example. > > James > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
