On Thu, Jun 4, 2015 at 10:56 PM, 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.Right, I tend to come from the Keykos angle where passing a capability to something does not implicitly give you the ability to construct other capabilities of that type, and constructors /can/ be wrapped by whomever, this leads me to think that there can be some subprogram where the 'Triangle' type and it's values conform to the RightTriangle constraint, but this is not the case if you can take them apart and put them back together with other values. I think it works for the limited scope of functional programming languages because functional programming languages tend to shed authority as they call functions with only the necessary arguments. as an example, a function which accepts 2 pairs is going to be fairly rare, so you need not worry that they have implicit authority to transform the 2 pairs (a1, b1), (a2, b2) into, a1, b1, a2, b2, (a1, b2), and (a2, b1) where most any other types of programming tend to accrue authority... _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
