Context Bounds for Polymorphic Functions #21643

KacperFKorban · 2024-09-25T08:12:58Z

Implement the #6 point form SIP-64 i.e.

6. Context Bounds for Polymorphic Functions

Currently, context bounds can be used in methods, but not in function types or function literals. It would be nice propose to drop this irregularity and allow context bounds also in these places. Example:

type Comparer = [X: Ord] => (x: X, y: X) => Boolean
val less: Comparer = [X: Ord as ord] => (x: X, y: X) =>
  ord.compare(x, y) < 0

The expansion of such context bounds is analogous to the expansion in method types, except that instead of adding a using clause in a method, we insert a context function type.

For instance, the type and val definitions above would expand to

type Comparer = [X] => (x: X, y: X) => Ord[X] ?=> Boolean
val less: Comparer = [X] => (x: X, y: X) => (ord: Ord[X]) ?=>
  ord.compare(x, y) < 0

The expansion of using clauses does look inside alias types. For instance,
here is a variation of the previous example that uses a parameterized type alias:

type Cmp[X] = (x: X, y: X) => Boolean
type Comparer2 = [X: Ord] => Cmp[X]

The expansion of the right hand side of Comparer2 expands the Cmp[X] alias
and then inserts the context function at the same place as what's done for Comparer.

Currently missing:

Support for poly functions that only have context bound term parameters

KacperFKorban · 2024-09-27T13:24:40Z

@odersky Could you take a look and see if there is something fundamentally wrong with this approach?

On a slightly different note:
What is the motivation for following aliases? I'm not sure how exactly it should work and how to fit it nicely into the current design, which does most of the transformations in desugaring. Should it only expand aliases and not other type parameters or match types?
Should we for example be able to represent the following declaration in TASTY?
type Comparer3[F[_]] = [X: Ord] => (x: X, y: X) => F[Boolean]

compiler/src/dotty/tools/dotc/typer/Typer.scala

tests/pos/contextbounds-for-poly-functions.scala

compiler/src/dotty/tools/dotc/ast/Desugar.scala

odersky · 2024-09-30T18:29:27Z

About aliases:

type Cmp[X] = (x: X, y: X) => Ord[X] ?=> Boolean
type Comparer2 = [X: Ord] => Cmp[X]

The tricky part is, say you have

val f =  [X; Ord] => (x: X, y: X) => Ord[X] ?=> true

Does f: Comparer2 hold?

odersky · 2024-09-30T20:04:08Z

Also, we don't need to put this modularity anymore since SIP 64 got accepted.

KacperFKorban · 2024-10-01T14:12:16Z

@odersky I'm not entirely sure that I understand your aliases example.
Do you mean that we need some normalization mechanism to eliminate redundant context functions? Or not generate them when they are unnecessary?

e.g.

[X: Ord] => (x: X, y: X) => Ord[X] ?=> Boolean
===>(desugar)
[X] => (x: X, y: X) => Ord[X] ?=> Ord[X] ?=> Boolean
===>(normalize)
[X] => (x: X, y: X) => Ord[X] ?=> Boolean

odersky · 2024-10-01T14:42:25Z

Well, does f: Comparer2 hold or not? I guess it depends how Comparer2 is expanded. I believe it should hold.

KacperFKorban · 2024-10-01T14:58:05Z

It doesn't hold now. I'll try moving the expansion later, to be able to use some type info then.

KacperFKorban · 2024-10-08T09:41:22Z

@odersky I rewrote the whole implementation to first mark apply methods in PolyFunctions and insert the context parameters after that when typing.
The missing part is the support for PolyFunctions that only have context bounds with an alias result e.g. [X: Ord] => SomeAlias[X]. This is mainly because the compiler assumes in a few places, that a PolyFunction has exactly one type param clause and exactly one term param clause. Do you have any advice for me strictly regarding the implementation?

bishabosha · 2024-10-19T13:35:21Z

I guess this should be merged in 3.7 now? @KacperFKorban @WojciechMazur

Gedochao · 2024-10-21T12:58:13Z

I guess this should be merged in 3.7 now? @KacperFKorban @WojciechMazur

+1, it's too late for this to be included in 3.6 (unless it's behind an experimental flag)

Gedochao · 2024-10-30T15:44:53Z

@bishabosha @KacperFKorban Actually, it seems we will be backporting this change to 3.6.2 (which, despite appearances, is technically considered the first stable version in the 3.6.x line).

soronpo · 2024-10-30T21:04:30Z

@bishabosha @KacperFKorban Actually, it seems we will be backporting this change to 3.6.2 (which, despite appearances, is technically considered the first stable version in the 3.6.x line).

I don't know if it was considered, but you could skip to 3.7.0 and declare all 3.6.x as invalid.

Gedochao · 2024-10-31T07:37:59Z

@bishabosha @KacperFKorban Actually, it seems we will be backporting this change to 3.6.2 (which, despite appearances, is technically considered the first stable version in the 3.6.x line).

I don't know if it was considered, but you could skip to 3.7.0 and declare all 3.6.x as invalid.

It was considered, but we decided to keep 3.6.x instead.

odersky

Code is good, with scope for some better comments. We need to refine the logic where evidence parameters are added.

compiler/src/dotty/tools/dotc/ast/Desugar.scala

odersky · 2024-11-04T13:17:50Z

compiler/src/dotty/tools/dotc/ast/Desugar.scala

@@ -508,7 +514,24 @@ object desugar {
      case Nil =>
        params :: Nil

-    cpy.DefDef(meth)(paramss = recur(meth.paramss))
+    def pushDownEvidenceParams(tree: Tree): Tree = tree match


It would be good to add a doc comment explaining what it does.

odersky · 2024-11-04T14:21:20Z

compiler/src/dotty/tools/dotc/typer/Typer.scala

+  /** Push down the deferred evidence parameters up until the result type is not
+   *  a method type, poly type or a function type
+   */
+  private def pushDownDeferredEvidenceParams(tpe: Type, params: List[untpd.ValDef], span: Span)(using Context): Type = tpe.dealias match {


I believe this is too coarse. If the evidence parameter is named, a parameter could already refer in its type to it. So the clause has to go just in front of this parameter, as is explained in Section 3 of SIP 64 and implemented in Desugar.addEvidenceParams. We should see how we can re-use this logic.

noti0na1 · 2024-11-05T14:29:20Z

Will nested polymorphic functions work? like [X: A] => X => [Y: B] => Y => Z

WojciechMazur · 2024-11-11T11:12:57Z

Do we have any estimation of when this PR could be finalized?
We concluded that we want to have it in 3.6, so it's becoming a blocker for a stable release. The cutoff for 3.6.3 (current development cycle) is on 19th November, so next week. We'd prefer to have at least 3.6.2-RC1 by this date.

KacperFKorban · 2024-11-11T11:33:31Z

I'll try to address the review comments today/tomorrow.

WojciechMazur · 2024-11-14T10:16:37Z

ping

…gant

…ction type definitions

…plementation consistent with addEvidenceParams

…e no context bounds

noti0na1

Some small questions. I think we should have at least a simple run test to ensure the context parameters are working. Otherwise, LGTM.

compiler/src/dotty/tools/dotc/typer/Typer.scala

KacperFKorban · 2024-11-15T15:32:37Z

@odersky I changed the implementation to reuse the logic from addEvidenceParams. This makes the desugaring consistent with the way we insert evidence parameters into methods.
For a poly function [X: {TC as tc}] => Params => Res, the TC evidence parameter will:

replace Params, if any of Params references tc, and Params will be moved as parameters to a result function -- [X] => (tc: TC) ?=> Params => Res
be inserted into Params, if Params are given/implicit parameters -- [X] => (Params ++ (tc: TC)) ?=> Res
otherwise, tc will be added as contextual parameters to the resulting function -- [X] => Params => (tc: TC) ?=> Res

odersky

Overall, nice factoring of the common logic. I have only minor change requests.

compiler/src/dotty/tools/dotc/ast/Desugar.scala

Backports #21643 to the 3.6.2. PR submitted by the release tooling.

bishabosha · 2024-11-24T01:40:18Z

compiler/src/dotty/tools/dotc/parsing/Parsers.scala

@@ -3460,7 +3460,9 @@ object Parsers {
            else ident().toTypeName
          val hkparams = typeParamClauseOpt(ParamOwner.Hk)
          val bounds =
-            if paramOwner.acceptsCtxBounds then typeAndCtxBounds(name) else typeBounds()
+            if paramOwner.acceptsCtxBounds then typeAndCtxBounds(name)
+            else if in.featureEnabled(Feature.modularity) && paramOwner == ParamOwner.Type then typeAndCtxBounds(name)


why does this need the modularity import? isn't it part of SIP-64 so should be enabled without a feature?

Hmmm, I assumed that, since it was meant to be pushed to the next minor, it should be under a language import.
If it's not, can we still do another RC/backport?
@WojciechMazur

Yes, we should fix that in the followup and backport to RC2.
This PR was explicitly marked as one of the things that should be included in 3.6

odersky reviewed Sep 30, 2024

View reviewed changes

odersky mentioned this pull request Oct 14, 2024

Implement SIP 64 as non-experimental #21668

Merged

KacperFKorban changed the title ~~[WIP] Context Bounds for Polymorphic Functions~~ Context Bounds for Polymorphic Functions Oct 18, 2024

bishabosha added the needs-minor-release This PR cannot be merged until the next minor release label Oct 19, 2024

KacperFKorban marked this pull request as ready for review October 23, 2024 07:40

Gedochao assigned odersky Oct 30, 2024

Gedochao requested a review from noti0na1 October 30, 2024 15:43

Gedochao assigned noti0na1 Oct 30, 2024

odersky requested changes Nov 4, 2024

View reviewed changes

odersky assigned noti0na1 and KacperFKorban and unassigned odersky and noti0na1 Nov 4, 2024

WojciechMazur mentioned this pull request Nov 6, 2024

[docs] Context bounds in polymorphic functions targets 3.7 #21822

Closed

KacperFKorban added 7 commits November 14, 2024 12:18

Make the expandion of context bounds for poly types slightly more ele…

a736592

…gant

Add more aliases tests for context bounds with poly functions

0af8397

Bring back the restriction for requiring value parameters in poly fun…

9c66069

…ction type definitions

Cleanup dead code

ec6d7ef

Reuse addEvidenceParams logic, but no aliases

dfa9240

Cleanup context bounds for poly functions implementation, make the im…

7755e3b

…plementation consistent with addEvidenceParams

More cleanup of poly context bound desugaring

24e3fa0

KacperFKorban force-pushed the context-bounds-for-poly-functions branch from 72d4d35 to 24e3fa0 Compare November 14, 2024 13:19

Short circuit adding evidence params to poly functions, when there ar…

f292ac5

…e no context bounds

noti0na1 requested changes Nov 14, 2024

View reviewed changes

compiler/src/dotty/tools/dotc/typer/Typer.scala Outdated Show resolved Hide resolved

compiler/src/dotty/tools/dotc/typer/Typer.scala Outdated Show resolved Hide resolved

Add a run test for poly context bounds; cleanup typer changes

f9db9fa

noti0na1 approved these changes Nov 15, 2024

View reviewed changes

KacperFKorban requested a review from odersky November 15, 2024 11:47

tgodzik added the release-notes Should be mentioned in the release notes label Nov 18, 2024

KacperFKorban assigned odersky and unassigned noti0na1 and KacperFKorban Nov 18, 2024

odersky requested changes Nov 18, 2024

View reviewed changes

odersky assigned KacperFKorban and unassigned odersky Nov 18, 2024

Cleanup context bounds for poly functions implementation after review

952eff7

odersky approved these changes Nov 18, 2024

View reviewed changes

WojciechMazur mentioned this pull request Nov 18, 2024

Backport "Context Bounds for Polymorphic Functions" to 3.6 #21972

Merged

WojciechMazur merged commit 5611522 into scala:main Nov 19, 2024
29 checks passed

WojciechMazur added a commit that referenced this pull request Nov 19, 2024

Backport "Context Bounds for Polymorphic Functions" to 3.6 (#21972)

059c539

Backports #21643 to the 3.6.2. PR submitted by the release tooling.

WojciechMazur added the backport:done This PR was successfully backported. label Nov 19, 2024

WojciechMazur added this to the 3.6.2 milestone Nov 19, 2024

bishabosha reviewed Nov 24, 2024

View reviewed changes

sjrd deleted the context-bounds-for-poly-functions branch November 24, 2024 05:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Context Bounds for Polymorphic Functions #21643

Context Bounds for Polymorphic Functions #21643

KacperFKorban commented Sep 25, 2024 •

edited

Loading

KacperFKorban commented Sep 27, 2024

odersky commented Sep 30, 2024

odersky commented Sep 30, 2024

KacperFKorban commented Oct 1, 2024 •

edited

Loading

odersky commented Oct 1, 2024

KacperFKorban commented Oct 1, 2024

KacperFKorban commented Oct 8, 2024

bishabosha commented Oct 19, 2024

Gedochao commented Oct 21, 2024 •

edited

Loading

Gedochao commented Oct 30, 2024

soronpo commented Oct 30, 2024

Gedochao commented Oct 31, 2024

odersky left a comment

odersky Nov 4, 2024

odersky Nov 4, 2024 •

edited

Loading

noti0na1 commented Nov 5, 2024

WojciechMazur commented Nov 11, 2024

KacperFKorban commented Nov 11, 2024

WojciechMazur commented Nov 14, 2024

noti0na1 left a comment

KacperFKorban commented Nov 15, 2024

odersky left a comment

bishabosha Nov 24, 2024

KacperFKorban Nov 24, 2024

WojciechMazur Nov 24, 2024

KacperFKorban Nov 25, 2024

Context Bounds for Polymorphic Functions #21643

Context Bounds for Polymorphic Functions #21643

Conversation

KacperFKorban commented Sep 25, 2024 • edited Loading

6. Context Bounds for Polymorphic Functions

KacperFKorban commented Sep 27, 2024

odersky commented Sep 30, 2024

odersky commented Sep 30, 2024

KacperFKorban commented Oct 1, 2024 • edited Loading

odersky commented Oct 1, 2024

KacperFKorban commented Oct 1, 2024

KacperFKorban commented Oct 8, 2024

bishabosha commented Oct 19, 2024

Gedochao commented Oct 21, 2024 • edited Loading

Gedochao commented Oct 30, 2024

soronpo commented Oct 30, 2024

Gedochao commented Oct 31, 2024

odersky left a comment

Choose a reason for hiding this comment

odersky Nov 4, 2024

Choose a reason for hiding this comment

odersky Nov 4, 2024 • edited Loading

Choose a reason for hiding this comment

noti0na1 commented Nov 5, 2024

WojciechMazur commented Nov 11, 2024

KacperFKorban commented Nov 11, 2024

WojciechMazur commented Nov 14, 2024

noti0na1 left a comment

Choose a reason for hiding this comment

KacperFKorban commented Nov 15, 2024

odersky left a comment

Choose a reason for hiding this comment

bishabosha Nov 24, 2024

Choose a reason for hiding this comment

KacperFKorban Nov 24, 2024

Choose a reason for hiding this comment

WojciechMazur Nov 24, 2024

Choose a reason for hiding this comment

KacperFKorban Nov 25, 2024

Choose a reason for hiding this comment

KacperFKorban commented Sep 25, 2024 •

edited

Loading

KacperFKorban commented Oct 1, 2024 •

edited

Loading

Gedochao commented Oct 21, 2024 •

edited

Loading

odersky Nov 4, 2024 •

edited

Loading