2010
DOI: 10.1145/1932682.1869489
|View full text |Cite
|
Sign up to set email alerts
|

Type classes as objects and implicits

Abstract: Type classes were originally developed in Haskell as a disciplined alternative to ad-hoc polymorphism. Type classes have been shown to provide a type-safe solution to important challenges in software engineering and programming languages such as, for example, retroactive extension of programs. They are also recognized as a good mechanism for concept-based generic programming and, more recently, have evolved into a mechanism for type-level computation.This paper presents a lightweight approach to type classes i… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
1
1
1

Citation Types

1
49
0

Year Published

2012
2012
2019
2019

Publication Types

Select...
6
1
1

Relationship

0
8

Authors

Journals

citations
Cited by 41 publications
(50 citation statements)
references
References 42 publications
1
49
0
Order By: Relevance
“…This is similar to methods in objectoriented programming whose availability depends on type parameters [28], but here we see that this feature arises "mechanically" by the de/refunctionalization correspondence. We see again how both impossible equations and the need to access constructor type arguments translate naturally into corresponding features in the codata world.…”
Section: Informal Overviewsupporting
confidence: 59%
“…This is similar to methods in objectoriented programming whose availability depends on type parameters [28], but here we see that this feature arises "mechanically" by the de/refunctionalization correspondence. We see again how both impossible equations and the need to access constructor type arguments translate naturally into corresponding features in the codata world.…”
Section: Informal Overviewsupporting
confidence: 59%
“…The use of Scala's mirror-based reflection requires an adjustment on the types of the combinators in Algebra. The combinators now need to take an additional implicit parameter [40] m, which contains a reflective description of type parameters. This additional parameter does not affect client code since it is implicitly inferred and passed by the Scala compiler.…”
Section: Default Combinator Implementations Using Reflectionmentioning
confidence: 99%
“…In Scala, requirements on a type parameter can be expressed with a trait. It can be implemented in a so-called object, and automatically selected for instantiation using the implicit mechanism [OMO10]. Regarding the expressive power of these approaches, all of them are comparable to our basic binding mechanism plus adapters.…”
Section: Related Workmentioning
confidence: 99%