Skip to content

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

Merged
merged 5 commits into from
Dec 1, 2017
Merged

Add 0.5 docs #3579

merged 5 commits into from
Dec 1, 2017

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Nov 28, 2017

No description provided.

@odersky odersky requested a review from allanrenucci November 28, 2017 17:08

(k: Keyed) => k.Key

This type describes function values that take an argument `x` of type
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's k, not x (same on the next line)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, k is the parameter. I wanted to use a different name for the argument.

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 }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keyed and Key are a bit too easy to confuse when following the example. I would maybe replace Keyed by Entry.

Copy link
Contributor Author

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.


This query would now be classified as ambiguous. This makes sense, after all
there are two possible solutions, `b(a1)` and `b(a2)`, neither of which is better
than the other and both of which are better than the third solution, `c`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are b(a1) and b(a2) better than c?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because their return type is a subtype is of the return type of c

and the query `implicitly[C]`.

This query would now be classified as ambiguous. This makes sense, after all
there are two possible solutions, `b(a1)` and `b(a2)`, neither of which is better
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3 solutions?

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so that

def apply(x1: K1, ..., xN: KN): R
}

where the result type parameter `R` is an upper approximation of the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

R'?

They do not work in code, which is where we would have needed them.
@@ -0,0 +1,50 @@
---
layout: doc-page`%
title: "Dependent`% Function Types"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the `% for?

there are two possible solutions, `b(a1)` and `b(a2)`, neither of which is better
than the other and both of which are better than the third solution, `c`.
By contrast, Scala 2 would have rejected the search for `A` as
ambiguous, and subsequently have classified the query `b(implictly[A])` as a normal fail,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo 'implictly'

@allanrenucci allanrenucci self-assigned this Dec 1, 2017
@allanrenucci allanrenucci merged commit ca0725b into scala:master Dec 1, 2017
@allanrenucci allanrenucci deleted the add-0.5-docs branch December 1, 2017 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants