> 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
