On Fri, Jun 5, 2015 at 1:56 AM, Keean Schupke <ke...@fry-it.com> wrote: > > On 4 Jun 2015 22:16, "Matt Rice" <ratm...@gmail.com> wrote: >> I tend to agree, this is in part why I was yammering about >> constructors & first class constructors & the ability to wrap >> constructors with regards to the >> >> struct Triangle { Point a; Point b; Point c; } >> vs struct RightTriangle { Point a; Point b; Point c;} example.... >> >> because it makes sense to put the constraint checking at the >> constructor precisely so that every function that depends upon the >> RightTriangle assertion relies on the fact that the assertion was done >> at construction time, rather than doing the the assertion in every >> function depends on RightTriangle constraint. > > Haskell used to allow this, but it has been deprecated. It turns out to be > bad for code reuse. The idea is in functional programming we prefer simple > general types like "pair" and we don't re-invent them for every pair of > properties. > > For example you are better off using a tuple of the points (where points > itself is a tuple) and using type synonyms. > > You do not want to have to redefine the area function for every kind of > triangle, so by putting the RightTriangle constraints in the type you force > unnecessary duplication of generic functions. > > By putting the constraints in the functions you limit the use of algorithms > that rely on the rightness of the triangle where they belong.
I don't know which Haskell feature you're talking about, but if RightTriangle were a refinement of Triangle, then it'd be a subtype, so you could call "area", which takes a Triangle, with a RightTriangle. So you can associate rightness with the type _and_ get code reuse. What's more interesting is scaling, which works for any triangle, but also preserves rightness. (And so do rotation and translation.) These would have the intersection of two types: [other stuff]->Triangle->Triangle and [other stuff]->RightTriangle->RightTriangle _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev