Sorry, I'm lost. Why would having the type constraints in functions rather than the data-structures cause problems with authority?
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
