On Fri, Jun 5, 2015 at 2:23 AM, Keean Schupke <[email protected]> wrote: > Sorry, I'm lost. Why would having the type constraints in functions rather > than the data-structures cause problems with authority?
It doesn't i'm saying the authority to construct and destructure types implicitly is what causes you to have to check type constraints in functions rather than being able to rely on that constraint at some outer bounds > If you want to hide data and check authority you use an abstract data-type > where the accessor functions checks the authority. > > I program the same way in C++ (see Stepanov's "Elements of Programming"), so > it is nothing specific to functional programming. > > > Keean, > > > On 5 June 2015 at 10:01, Matt Oliveri <[email protected]> wrote: >> >> 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 > > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
