On Sun, Jul 20, 2014 at 8:00 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Wed, Jul 16, 2014 at 2:12 PM, Matt Rice <[email protected]> wrote: >> >> I think the best argument for it I have come up with is something like >> the following scenerio: >> >> we have a structure Triangle {pt1; pt2; pt3;} >> we have a structure much like a subtyping relationship with restricted >> values >> structure RightTriangle {pt1; pt2; pt3} where one of the angles must >> be 90 degrees, and for whatever reason we wish not to make >> RightTriangle opaque, to avoid the indirection of accessor functions >> for the values, > > > This can be viewed as type, or it can be viewed as a known constraint on a > value of some type. How do we want to think about this case?
Torn I suppose, there is an issue with the type as specified, it infers in all cases a Triangle would, therefore assuming a pythagorean interface which requires the constraint requires annotations, although it will be called with either without it, doing this as a 'known constraint on a value of some type' equates the calling of the constraint directly with the annotation, thus result of the constraint cannot infer incorrectly when the constraint is separate from type. so that is a win for 'as a known constraint on a value'... what I prefer about as a type/at construction time is that the constraint fails at construction time, not at some time in the future with the point of falure in some stack frame in the middle, further its simple to reason about where and when the constraint is called (it's called once at construction time), that is with the appropriate annotations it forces a) the constraint to be enforced at the point where the caller constructs the object to be passed in b) the constrained interface to expose the constraint to the caller. 'known constraint on a value of some type', i'm not sure if the key word 'known' restricts the called interface to declare a constraint or if it could declare it's own constraints on a value (passed in) and start enforcing those without really exposing the caller... something to avoid imo and 'as a type' has a fairly obvious con in that it could be seen as creating an explosion of various types.... con there is question as well if 'known constraint on a value' requires language support at all or simply defined within the confines of the language. I suppose the top issue is downright concerning while the rest seem annoying, and dependent on how these really are implemented/used, if we can get those properties I like out of separated constraints all the better... _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
