Talk:Parametric polymorphism
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||
|
To-do list for Parametric polymorphism:
|
"Let-polymorphism".
[edit]Does the let in the term let-polymorphism refer to some ML dialects' use of let to mean what Standard ML calls val? For a long time I was confused because I didn't see what it has to do with what SML called let, but I recently learned that OCaml uses let for val, and suddenly it seems to make sense . . . —RuakhTALK 06:48, 15 August 2013 (UTC)
- Milner's original type inference algorithm worked on an idealized programming language: a lambda-calculus with let-bindings. These let-bindings correspond approximately to SML's val-bindings, although things get a bit more tricky when you also have to take mutually recursive definitions and the value restriction into account. —Ruud 14:30, 15 August 2013 (UTC)
Traits and Parametric Polymorphism
[edit]After reading through this article, and the article on trait (computer programming), I'm having trouble distinguishing between the two concepts: they seem to be talking about the same thing, as best as I can tell. This article takes a decidedly computer-sciencey type-theoretic tack in it's presentation, while the article on traits seems to be more along the lines of ordinary programmers trying to wrap their minds around some new-fangled buzz-word. If there are differences, could these be explained? Could some examples be given? If it really is the same concept, could some clarifying discussion be added? 67.198.37.16 (talk) 16:15, 30 December 2021 (UTC)
- They do have in common the underlying concept of polymorphism, but they are different concepts. Parametric polymorphism is a formal property of typed lambda calculi and logics, whereas traits are a specific language construct. Traits provide one particular way of achieving ad-hoc polymorphism. In ad hoc polymorphism, "a polymorphic function can denote a number of distinct and potentially heterogeneous implementations depending on the type of argument(s) to which it is applied". Think of a trait as a function from a type (the class implementing the trait) to a record of functions (those methods belonging to the class that are required by the trait). Then this function can end up giving us "heterogeneous implementations" depending on the class it's applied to. E.g., consider the
trait Stringable = { val toString : self -> string }
. Now imagine implementingtoString
forclass String extends Stringable
forclass Int extends Stringable
. The two implementations will end up quite different. But in the case of, e.g., theappend
function used as an example in this article, the exact same implementation is used for bothappend : [Int] x [Int] -> [Int]
and forappend : [String] x [String] -> [String]
. - Do you think it would help improve the clarity of these two articles and their relation by
-
- Making it explicit on trait that this is a form of ad-hoc polymorphism
- Ensure traits are mentioned as a common approach to ad-hoc polymorphism on that page?
- Synechist (talk) 21:19, 28 February 2022 (UTC)