Jonathan S. Shapiro
shap at eros-os.com
Tue Mar 25 16:33:40 EDT 2008
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.
> bitc-dev mailing list
> bitc-dev at coyotos.org
More information about the bitc-dev