On Mon, Feb 9, 2015 at 9:53 AM, Keean Schupke <[email protected]> wrote:
> The comprehension does not need to know the types as it can use > type-classes. > I already got that part. Perhaps my question will be clearer if I state the concrete question that I'm actually trying to understand. I understand how to do the type inference for "for x in input". The "input" is some type 'aggregate satisfying the "interable 'aggregate 'elemType" constraint, which in turn means that the type of x is 'elemType. So far so good. And when I look at something like [ toUpper c | c <- s:String ] I'm also clear what the element type is of the *output*. It's whatever the result type is for the expression on the left of the vertical bar. Good. The reason I'm asking what collection type the *result* collection has is that I don't see how to infer it. If I ignore those outer square brackets for a moment, and look only at the expression ((toUpper c): 'returnedElemType | c <- s:String) then I'm clear that that we're looking for a result of some type 'comprehensionResultType s.t. "appendable 'comprehensionResultType 'resultElemType" is satisfied. Up to that step, I think that we are all in fairly complete agreement, setting aside minor quibbles about whether it's an iterable or a collection, and whether one or the other of us has made a typo somewhere. But now I'm looking at that outermost expression, which is of the form: [ expr : 'comprehensionResultType ] And that's damned odd, because I would normally look at "[ expr ]", and conclude that the result should be a single element list! So what is it here that justifies us in producing a multi-element list? I see two possible ways to look at this. The first is that we have a productions that looks like: expr := expr '|' generator expr := '[' expr ']' But that would lead to the conclusion that the result should be a single element list. The other option is that we have a production somewhere that looks like: expr := '[' expr '|' generator ']' But that would appear to lead to the conclusion that we are only able to use comprehensions to produce a limited number of types that are syntactically known to the parser. What I think I would prefer here is the first set of productions, along with a story that justifies treating the generated result set as something other than than a singleton element. Alternatively, perhaps there is some way to recognize the special case that x, y, z satisfies "'appendable 'type 'elemType" in the case where the types of x, y, z are the same. So I'm trying to understand the derivation that leads us to correctly infer the output type, and whether the grammar has to admit special cases to do support it. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
