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

Reply via email to