-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add 0.5 docs #3579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 0.5 docs #3579
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
--- | ||
layout: doc-page | ||
title: "Dependent Function Types" | ||
--- | ||
|
||
A dependent function type describes functions where the result type may depend | ||
on the function's parameter values. Example: | ||
|
||
class Keyed { type Key; key: Key } | ||
|
||
def extractKey(k: Keyed): k.Key = k.key // a dependent method | ||
val extractor: (k: Keyed) => k.Key = extractKey // a dependent function value | ||
|
||
Scala already has _dependent methods_, i.e. methods where the result | ||
type refers to some of the parameters of the method. Method | ||
`extractKey` is an example. Its result type, `k.key` refers its | ||
parameter `k` (we also say, `k.Key` _depends_ on `k`). But so far it | ||
was not possible to turn such methods into function values, so thay | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. so that |
||
they can be passed as parameters to other functions, or returned as | ||
results. Dependent methods could not be turned into functions simply | ||
because there was no type that could describe them. | ||
|
||
In Dotty this is now made possible. The type of the `extractor` value above is | ||
|
||
(k: Keyed) => k.Key | ||
|
||
This type describes function values that take an argument `x` of type | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, |
||
`Keyed` and return a result of type `x.Key`. | ||
|
||
Recall that a normal function type `A => B` is represented as an | ||
instance of the `Function1` trait (i.e. `Function1[A, B]`) and | ||
analogously for functions with more parameters. Dependent functions | ||
are also represented as instances of these traits, but they get an additional | ||
refinement. In fact, the dependent function type above is just syntactic sugar for | ||
|
||
Function1[Keyed, Keyed#Key] { | ||
def apply(k: Keyed): k.Key | ||
} | ||
|
||
In general, a dependent functon type `(x1: K1, ..., xN: KN) => R` of arity `N` | ||
translates to | ||
|
||
FunctionN[K1, ..., Kn, R'] { | ||
def apply(x1: K1, ..., xN: KN): R | ||
} | ||
|
||
where the result type parameter `R` is an upper approximation of the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
true result type `R` that does not mention any of the parameters `k1, ..., kN`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keyed
andKey
are a bit too easy to confuse when following the example. I would maybe replaceKeyed
byEntry
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, let's do this.