On Sun, Feb 8, 2015 at 10:27 AM, Keean Schupke <[email protected]> wrote:
> For me the most useful part of comprehension notation is the implicit > 'cartesian product', which other wise involves nested loops. It would be > best defined generically over containers using iterators. > That makes sense, but it isn't really addressing the question I was trying to ask. It's very possible that I don't have my terms right in this area. In my view - and please correct me if I have my terms wrong - a comprehension consists of a generator expression and a construction. The generator expression produces some form of collection. The construction takes this collection and turns it into some particular comprehended type (list, array, vector, possibly others). My question is: how do we get from the (arbitrary) collection to the (desired) final type? I'm especially mixed up about this when the desired final type is a sum type, because there is no obvious constructor to call. Is there some tricky thing going on here that allows us to infer the final desired type and build it directly as the generator executes? I confess I'm not seeing how that would work for array and vector comprehensions, where the size must be known in advance. Or should I stop trying to think of this as a construction problem, take the view that the generator produces a collection, and that the conversion to the final type is done by calling a function on that? in that view I can think about applying mixfix-like notions as a way to extend the comprehension constructs. So far as I know, all of the languages that do comprehensions only know how to do them over a "built in" set of types that are known to the parser. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
