My point is that the comprehension can be applied more generally. There is no need for it to be a strictly pure concept, infact on the readability thread it was clear that mutation of objects was considered more readable that composing maps and folds. The clever thing is that we can map the mutable constructs into a pure type system using monads like StateT, so that the state is threaded. Conceptually there is nothing impure going on at all, as we take the original object, plus the change and return a new updated object, threading the state through the monad.
However what I like is once you have modelled the semantics using pure lambda calculus and type-system, you do not actually have to implement it that way. The compiler could compile the mutable objects directly to C++ like objects. Keean. On 10 February 2015 at 17:57, Jonathan S. Shapiro <[email protected]> wrote: > On Tue, Feb 10, 2015 at 12:34 AM, Keean Schupke <[email protected]> wrote: > >> In general collections need to be mutable to be 'pushed' into. Only the >> special case of a singly linked list (or some trees with no backlinks) is >> this possible. >> > > Does it follow that comprehensions are a non-pure concept? Or does the > rewrite rely on a monad? > > I'm still not convinced that we want to think of the output as a > collection. An output collection is certainly one option, but it seems to > me that the real requirement is the ability to implement something > equivalent to "append". So, for example, a vector as output is > (inefficiently) possible if we are willing to build a new vector for each > element, increasing the length by one each time we "append" an element. A > vector clearly isn't a collection. > > I don't mean to suggest that this is the "right" way to do it. I'm only > trying to point out that we don't need to rely on mutation to make > comprehensions work. > > > shap > > _______________________________________________ > 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
