It sounds like our opinions are pretty close, and I accept your reason for the sting to list example :-)
Lets look at mutation, and what we mean by a non-mutating idiom. I assume from your monads comment you are taking the ML approach using references and an impure arrow (IE any function arrow can have side effects). In this case all the type system complexity goes away so mutable vs immutable is not so much of an issue. For the comprehension, if you allow mutable collections, they do not have to be mutable, in other words a singly-linked-list is a special case that does not require mutability, but you can still treat it as mutable (for example the StateT monad transformer). So if an immutable list, and a mutable hash-table can both have the same 'extensible' interface, and the generic comprehension can be defined in terms of this, what is the problem? I don't see the need to have two syntaxes one for a comprehension that writes to a mutable data-structure, and one that writes to an immutable data-structure. 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. 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. Keean. On 10 February 2015 at 19:58, Jonathan S. Shapiro <[email protected]> wrote: > On Tue, Feb 10, 2015 at 10:15 AM, Keean Schupke <[email protected]> wrote: > >> A further point would be if you can iterate a String, why would you want >> to convert it into a List? >> > > Well, speaking hypothetically, of course, you might want to do so in order > to ask ignorant questions about comprehensions.... > > >> The tendency to convert everything to lists for processing is working >> around a deficiency in the design of the language. >> > > In part, I think you are saying that we really need a generalized notion > of iterable things. I agree. I also think that if we *are* going to build > an output aggregate, it's useful to be able to produce whatever type is > needed without going through a list as an intermediate form. > > The main difference I see between comprehensions and nested iterations is > that the comprehension provides a syntactically clearer way to express the > fabrication. You can certainly do that with nested iterations, but it tends > to need a mutable idiom. I don't object to mutation, certainly, but it's > useful to have a non-mutating idiom available. > > You have talked about using a monad in all this. I'm not planning any > intrinsic support for monads in the BitC core. > > Generic iterators allow algorithms to be expressed in a way that they do >> not rely on the type of the collection being a list, but intact relate the >> algorithm directly to the access-pattern required (forward, bi-direction, >> indexed, random, bifurcating, 2-dimensional etc...). >> > > I agree. Though I also find the sheer complexity of the various iterator > schemes in the standard C++ library bewildering. > > > 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
