On 5 June 2015 at 11:36, Matt Rice <ratm...@gmail.com> wrote: > On Fri, Jun 5, 2015 at 2:46 AM, Keean Schupke <ke...@fry-it.com> wrote: > > I don't understand, you just use type-classes: > > > > area :: (RightTriangle a b, Numeric b) => a -> b > > > > RightTrianlge is a constraint on the polygon "a" with points of type "b" > > (Int or Float etc). > > > > Only the algorithm used in areaOfRightTriangle knows the type of triangle > > required for the area operation, not the triangle itself. > > > > I can have other triangle area definitions too: > > > > area :: (Square a b, Numeric b) => a -> b > > > > WIth suitable overloads I can call 'area' on any polygon, and I will get > the > > most efficient algorithm for that type of polygon automatically. > > > > I guess I don't understand how this in any way affects what I was > replying to, which was coalescing assertions on types that were not > abstract... > > but in reality probably just more comfortable/familiar with the keykos > model of lambda calculus which doesn't assume you'd ever want to give > out a constructor...
My point was you do not want assertions on types, abstract or not. The assertions belong on the functions, as it is the algorithms that have the requirements not the data. None of this requires you to give out a constructor. In fact we don't know the type of 'a' the polygon container so we cannot deconstruct it, we use the abstract interface, which is probably an Iterator. The type class "RightTriangle" can be seen as a witness to the proof that the value passed to the function is a right-triangle. You don't have to do this proof for every function, as only right-triangles would be a member of this type-class. Keean.
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
