On Fri, Jun 5, 2015 at 2:01 AM, 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.
I'm probably using a bad definition of authority specifically as it applies to control flow... >> 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. I mean when using a type (unlike a tuple), most easily seen via a class, where the object collects authority in the class, and distributes it out to methods, vs, the typical functional style where authority is accrued at top-level in a tuple-like structure and reduces by being split in to smaller primitive types when passed to functions. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
