On Sat, Dec 27, 2014 at 10:38 AM, Matt Oliveri <[email protected]> wrote:
> On Sat, Dec 27, 2014 at 1:14 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > > But I think David isn't entirely right that this is a separate > compilation > > issue. I think the real issue lies in the fact that the type system that > > survives to the late binding stage doesn't admit all of the constraints > you > > might want. > > I still don't follow. Constructors in the patterns are not generic; > why would we need fancy constraints? The types matched against can and > should be heavily constrained to specific type constructors. > Right. And the problem is that that sort of constraint is horribly too strong for some use cases. Consider an example: def getX (ob : 'Ob) = ob.x val getX : HasField('Ob, 'x :: Ident, 'fieldType) => 'Ob -> 'fieldType If we can't express that hasField constraint at the separate compilation interface, then what we have here is an incomplete match (the match expression being the "." operator). Not all of the constraints we would like to express are constructor constraints. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
