Eff's effect system is actually using Monads, it just doesn't call them that. What Eff added was that it uses a Monad parameterised over a type level set. In Haskell you can use the existing Monads and type-level programming to create a set, so in effect you end up with the same thing that Eff has.
After all, from a type system point of view, every statement in C/C++ is in the IO monad. Keean. On 10 February 2015 at 20:21, Raoul Duke <[email protected]> wrote: > > In any case immutable is debatable. There is actually a write to memory, > > which mutates the memory cell in the memory array even in the list case, > so > > there is really no such thing as immutable. What there is, is a 'special' > > construction time when mutation is allowed, and then the object is > 'frozen' > > and becomes immutable. In this sense we can consider any mutable data > > structure to simply still be in construction, when we are finished we can > > freeze it, and it becomes immutable just like a list. This can be > > particularly elegant with comprehensions, when we might allow the > > comprehension to mutate the result object, but have it frozen > immediately. > > yes. This drives me up the wall in job interviews. :-) > > > Personally I would prefer control of side-effects via an effect system > based > > on Monads, but I can understand it might not be to everyone's tastes. > There > > is a nice port of an 'Eff' style effect system to Haskell using Monads > and > > type-indexed-types, which would be a good starting point. > > > Effect system, cool! Monad based? Errr, not so sure. There could be > other options. I guess monads are the most well known and used so they > are at least the devil people/we know. :-} > _______________________________________________ > 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
