tag:blogger.com,1999:blog-22587889.post4094338723803914012..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Scala Implicits : Type Classes Here I ComeAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-22587889.post-19517577736584819132014-09-05T03:19:23.703+05:302014-09-05T03:19:23.703+05:30The upside of Haskell's global "implicits...The upside of Haskell's global "implicits" namespace is that there is a notion of uniqueness of a type class instance for a given type. This means that we can talk about "the" equality of Ints or "the" order of, I dunno, free abelian groups.<br /><br />The important part of this is that we often do operate with certain properties like order as being fixed and depend upon that fixture in our programs. The classic example here is that in Scala you cannot be guaranteed that the sense of order you use to build a set is the same as the one you use to query it... and so you lose efficiency.<br /><br />Stable implicits can be annoying, though, when unicity isn't needed. For instance, it's not meaningful to pick "the" monoid underlying a ring although Haskell would ask you to.<br /><br />So I don't think either feature dominates the other.Joseph Abrahamsonhttp://tel.github.ionoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-34658858210279824722011-08-12T00:53:29.806+05:302011-08-12T00:53:29.806+05:30I wrote up another good (according to me :-) typec...I wrote up another good (according to me :-) typeclass example here: http://missingfaktor.blogspot.com/2011/08/emulating-cs-default-keyword-in-scala.htmlZimbabwe vgtjbkjkijhttps://www.blogger.com/profile/10950240139175717925noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-81461912241968414612010-06-25T00:03:15.722+05:302010-06-25T00:03:15.722+05:30"@Tom : regarding interfaces and type classes..."@Tom : regarding interfaces and type classes - interfaces do a subtype polymorphism while type classes do a parametric polymorphism. +1 on your thoughts and that's what I indicated in the post as well."<br /><br />This is incorrect, type-classes do not provide parametric polymorphism, type varibles do.<br /><br />Type-classes provide ad-hoc polymorphism in a <b>totally</b> type inferred language such as Haskell and bounded quantification of parametric polymorphism. <br /><br />You can write polymorphic functions in Haskell without type-classes constraints but without them you can not do much on values of a type variable.snk_kidnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-13820108914700956352010-06-23T13:36:59.207+05:302010-06-23T13:36:59.207+05:30I think I may have found my own answer. Have the T...I think I may have found my own answer. Have the Type Class Instance define a constant (method with no parameters) that returns a meta object describing the class.<br /><br />Which is rather more similar to the pre-annotations Hibernate *.cfg.xml files. *shudder*<br />So going that way would not improve type safety.MLeohttps://www.blogger.com/profile/15585061142493156677noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-51202983810972891442010-06-21T19:08:40.355+05:302010-06-21T19:08:40.355+05:30How would you capture something like JAXB (or Hibe...How would you capture something like JAXB (or Hibernate) using Type Classes? I'm not asking specifically for JAXB or Hibernate, but how you would "annotate" (perhaps "describe" is a better word here) a class as a type class instance.MLeohttps://www.blogger.com/profile/15585061142493156677noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-88938528262223377222010-06-21T12:22:22.540+05:302010-06-21T12:22:22.540+05:30@Eric : +1 on your thoughts. I think I penned my o...@Eric : +1 on your thoughts. I think I penned my observations on Twitter the day List Records was announced. I also wrote a follow up blog post http://debasishg.blogspot.com/2010/02/why-i-dont-like-activerecord-for-domain.html on the same topic. And here's a mail thread on my observations on the Lift ML .. http://scala-programming-language.1934581.n4.nabble.com/Lift-Record-td1960630.html ..<br /><br />In short I don't like the concept of bloating a domain object with accessory functionalities. You have nailed it absolutely right .. It's weird to have a Record object with a toXhtml method. This is a problem begging to be fixed with a type class.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-69010970935742105682010-06-21T12:17:40.252+05:302010-06-21T12:17:40.252+05:30@Tom : regarding interfaces and type classes - int...@Tom : regarding interfaces and type classes - interfaces do a subtype polymorphism while type classes do a parametric polymorphism. +1 on your thoughts and that's what I indicated in the post as well.<br /><br />Also your observation regarding the scope of a type class instance is true for Scala, which also I have detailed out.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-76858136139230561002010-06-21T05:25:36.014+05:302010-06-21T05:25:36.014+05:30Very useful post on the applicability of type clas...Very useful post on the applicability of type classes (as was Daniel's last post on the subject too). I've been bitten several times by the toXml, toHtml methods polluting my domain and I think this offers a good solution.<br /><br />2 more thoughts about that:<br /><br />- I think that Lift could benefit from this idea in its Records framework. I always found weird that a Record object had a toXhtml method<br /><br />- That may be a good way to implement the DCI architecture (http://bit.ly/c2ZpEM) where the type class is a specific role<br /><br />Eric.Erichttps://www.blogger.com/profile/16484514586929815703noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-31401774256638876692010-06-21T04:52:34.447+05:302010-06-21T04:52:34.447+05:30A crucial distinction between type classes and int...A crucial distinction between type classes and interfaces is that for class A to be a "member" of an interface it must declare so at the site of its own definition. By contrast, any type can be added to a type class at any time, provided you can provide the required definitions, and so the members of a type class at any given time are dependent on the current scope. Therefore we don't care if the creator of A anticipated the type class we want it to belong to; if not we can simply create our own definition showing that it does indeed belong, and then use it accordingly. So this not only provides a better solution than adapters, in some sense it obviates the whole problem adapters were meant to address.<br /><br />Another interesting point is that the particular <i>implementation</i> of a type class instance depends on scope. So, for example, you could feasibly define, in different scopes, two or more different implementations of the same type class for the same type.Tom Crocketthttps://www.blogger.com/profile/08187984533973895431noreply@blogger.com