On Sat, Dec 27, 2014 at 1:56 PM, Jonathan S. Shapiro <[email protected]> wrote: > 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: >> >> 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).
Oh, no no no! "." is not pattern matching. It's projection. This is not a counterexample. But I realized that we don't need to demand a specific type constructor. We can demand any type constructor which is a variant with a compatible set of value constructors. This is more general if you allow constructors to not be associated with a single type constructor. > Not all of the constraints we would like to express are constructor > constraints. Certainly, but I see that point as moot because for a real pattern match, there _should_ be a constructor constraint... Wait, um, does a "constructor constraint" say that a type is an [open] variant with a certain value constructor, or does it say it's an instance of a certain type constructor? _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
