On 4 Jun 2015 22:16, "Matt Rice" <[email protected]> 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.

Keean.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to