On Mon, Feb 9, 2015 at 3:22 PM, Geoffrey Irving <[email protected]> wrote:
> > Scala (and I believe Fortress) solve this by mechanically translating > comprehensions into iterated calls to flatMap / map / filter, and then > using whatever result types flatMap produces. E.g., > > zs = [ (x,y) | x <- xs; y <- ys ] > > would turn into > > zs = concatMap (x -> map (y -> (x,y)) ys) xs > > If concatMap can generate a certain collection type, so can > comprehensions. If the user wants to make a particular container use > extremely fancy ad-hoc techniques to be flexible, they can choose to > do that for the particular concatMap overloads. > That makes sense. And given the type class approach that Keean and I seem to be agreeing on, I know how to think about that. It seems a little odd to me that [ expr | generator ] is a syntactic construct unrelated to lists, but that's *all* it is - a bit odd. The consequence that I would pragmatically expect is that you'd end up with the type of the result set being underspecified in many cases, leading to a need for annotations to ensure that the result set type actually concretizes. The success of type classes at abstracting the type ends up leaving your waist size so abstract that your pants fall down. :-) > The place where this breaks down in scala is different container > types. E.g., you like a comprehension involving a list and an option > to produce a list (probably), but it is either a compile error or > something useless. That seems odd. I'm not sure I see how that would happen... shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
