On Fri, Jun 5, 2015 at 2:58 AM, Matt Rice <[email protected]> wrote: > On Thu, Jun 4, 2015 at 10:56 PM, Keean Schupke <[email protected]> wrote: >> >> 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. > > 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.
I didn't think functional languages had authority in the first place, aside from using resources, since there aren't side effects. > 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... I thought that although you have to pessimistically assume other programs accrue authority, most of them actually don't. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
