Proposal: Change `@` to `as` #9829

odersky · 2020-09-19T08:20:29Z

I have a late syntax change proposal: Change @ as the pattern matching binder to as.

Example:

  x match 
    case s as Success(x, in1) => ...
    case f as Failure(_, in1) => ...

  e match
    case (xs as hd :: tl, y) => ...

Why @ is not a good choice for pattern matching:

It is an obscure symbol with a different meaning. I find the two worst operators to use in programming languages are @ and $ since both have everyday uses that have nothing to do with their role in programming. We have avoided $ so far, let's get rid of @ as well.
It comes with the wrong precedence. @ binds more weakly than every other infix operator, yet being a non-standard symbol it would suggest that it binds more strongly.

By contrast, as is readable and it comes with the right precedence. It also reinforces learning in relation to givens. In both cases x as would be an optional label.

An objection could be that in patterns, as would be followed by a pattern whereas in givens it's followed by a type. But there's precedence for that: | plays a similar dual role: it connects patterns in patterns and types in types.

Migration

For 3.0, allow both as and @. For 3.1. either deprecate @ or disallow it altogether and offer an automatic rewrite.

The text was updated successfully, but these errors were encountered:

som-snytt · 2020-09-19T09:21:31Z

More precedence for precedence: lampepfl/dotty-feature-requests#120

Changing the symbol instead of the precedence feels quite normal.

Maybe allow case (xs @$ hd :: tl, y) => under -Xbad-@$s.

sjrd · 2020-09-19T10:27:36Z

TBH I don't like that we are still introducing completely new changes this late in the process. We're already swamped in changes that we cannot keep track of.

Independently of that, this seems to be a very cosmetic change that is not justified by anything else than "it does not look nice; let's use something nicer".

If we really have to change how binding works in pattern matching, I'd like something deeper. I would like a real analogy with |. I would like to express the example as:

  x match 
    case s & Success(x, in1) => ...
    case f & Failure(_, in1) => ...

  e match
    case (xs & hd :: tl, y) => ...

This is very semantic: I want the scrutinee to match both the pattern on the left (which is a capture, so a binding) and (&) the pattern on the right (which is destructuring). The captures/bindings on both sides of & would be visible in the guard and the body.

There would be no restriction on what we can put on the left and on the right. We could actually put a pattern on the left (I have occasionally wanted to match on something that had to satisfy two different patters/extractors). The very concept of a binding would cease to exist. All we would have would be captures. That would actually simplify the language.

odersky · 2020-09-19T10:41:23Z

@sjrd Rolling this into conjunction is indeed very elegant. But I believe it is also a lot more obscure for the reader who is not familiar with the idiom. For the cases with as it's immediately clear what they mean. For the cases with &, not so much.

odersky · 2020-09-19T10:49:55Z

Independently of that, this seems to be a very cosmetic change that is not justified by anything else than "it does not look nice; let's use something nicer".

It's more like: I find it awkward teaching this. Can we avoid that? It's not a matter of nicety but of promoting the right intuitions for students.

julienrf · 2020-09-19T11:22:06Z

I find @sjrd’s suggestion very elegant.

To add to Martin’s introductory post, here is what the proposal would look like in the other situations where we currently use @:

// val someX @ Some(x) = Some(42)
val someX as Some(x) = Some(42)

// for (xs @ hd :: tl <- eventuallyInts) ()
for (xs as hd :: tl <- eventuallyInts) ()

odersky · 2020-09-19T13:32:35Z

Note that as/@ is actually not completely subsumed by a hypothetical &. For instance, we use this pattern in Flags.scala:

val (_, Captured @ _, NoInits @ _) = newFlags(32, "<captured>", "<noinits>")

This makes an uppercase identifier a bound variable. I believe there's no other way to do this, except for writing separate val definitions.

LPTK · 2020-09-19T17:15:51Z

It's worth noting that both SML and OCaml use as for pattern binding, which I've always found very nice to read, especially as opposed to Haskell and Scala's cryptic @.

There was also the idea of allowing as inside expressions too, where it could play the role of an "inline" val binder, which can be useful when debugging, and in situations like:

val keys = Set(a as newKey("a"), b as newKey("b"), c as newKey("c"))

instead of the verbose:

val a = newKey("a")
val b = newKey("b")
val c = newKey("c")
val keys = Set(a, b, c)

He-Pin · 2020-09-19T19:58:35Z

Rust is currently using @, I think as is easier for beginners.

mpilquist · 2020-09-20T13:21:46Z

Would as be a soft keyword and hence still usable in type and term names?

odersky · 2020-09-20T14:28:57Z

Yes, as can stay a soft keyword. It would be interpreted as a binder only when used as an infix operator in patterns.

djspiewak · 2020-09-20T15:15:18Z

So I'm a fan of the proposed syntax, just not a fan of making more waves so late in the game. Most usage of Dotty right now is cross compiling with Scala 2, so it's not a huge impact, but I feel like the bar should be pretty high for such changes.

One immediate problem that this creates, for example, is the fact that "as" is actually a commonly used function name across the Cats ecosystem. I believe it's also quite common in a number of other libraries (with varying meaning). All of those would need to be stuffed into backticks during migration (this is a problem that "then" really doesn't have for some reason), and that's more pain on the ecosystem and more pain on users.

(Edit: the soft keyword proposal above resolves this concern)

If I could rewind a decade and make the change you're suggesting, I would be all in favor of it. But at this stage, I feel it's a little too much in a process which is already fraught with variables.

som-snytt · 2020-09-20T15:37:51Z

Worth noting that pattern alternation doesn't currently parse as infix:

scala> 42 match { case n @ 42 | 17 => n }
1 |42 match { case n @ 42 | 17 => n }
  |                ^^^^^^
  |                Illegal variable n in pattern alternative

Scala 2.12 allows an extractor named $bar:

scala> (42, 17) match { case n @ 42 `|` 17 => n }
val res3: (Int, Int) = (42,17)

odersky · 2020-09-20T15:58:48Z

@djspiewak One possibility would be to try it out now, and if anything major breaks backtrack. The only thing that would break is if some code uses as as an infix operator in patterns.

djspiewak · 2020-09-20T16:11:32Z

Lower case "as" can't be used infix in patterns without quoting (I believe) so I think that case is alright.

I'm cool with "try it and see", so long as we watch carefully as we do. 🙂

odersky · 2020-09-20T17:08:48Z

Lower case "as" can't be used infix in patterns without quoting (I believe) so I think that case is alright.

It can be used, actually:

case class as(x: Int, y: Int)
val x = as(1, 2) match
  case 1 as 2 => ???

But maybe nobody did use it that way.

Sciss · 2020-09-20T19:37:52Z

does that mean no Scala 2 source can be cross-compiled without resorting to 3.0-migration ? Because I'm now compiling many projects successfully, and they are all ok without 3.0-migration...

som-snytt · 2020-09-20T22:33:11Z

scala> val as = "(a*)(.*)".r
val as: scala.util.matching.Regex = (a*)(.*)

scala> "aaabbb" match { case as as bs => s"$as .. $bs" }
val res0: String = aaa .. bbb

but I'm willing to forgo this in future.

Edit: I just got the pun from earlier, "a process fraught with variables."

nafg · 2020-09-21T01:31:10Z

Regarding &, it's pretty easy to implement in userland, and I have. I might be misremembering, was it Spray that first used it? object & { def unapply[A](a: A) = (a, a) }

…

On Sun, Sep 20, 2020, 6:33 PM som-snytt ***@***.***> wrote: scala> val as = "(a*)(.*)".r val as: scala.util.matching.Regex = (a*)(.*) scala> "aaabbb" match { case as as bs => s"$as .. $bs" } val res0: String = aaa .. bbb but I'm willing to forgo this in future. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9829 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUCX5GGZDTKLCKDP6FLSGZ7LJANCNFSM4RS4MP7Q> .

NthPortal · 2020-09-21T03:32:41Z

does that not mean that as could be implemented the same way in userland? (roughly, excluding the nuisance about capitalization)

LPTK · 2020-09-21T06:34:37Z

@NthPortal it actually can:

scala> object as {
     |   def unapply[A](a: A) = (a, a)
     | }
// defined object as

scala> Some(1) match { case a as Some(x) => (a, x) }
val res2: (Some[Int], Int) = (Some(1),1)

Recommending the use of this operator (which would be added to Predef) and deprecating @ would be a nice way of simplifying the language.

tabdulradi · 2020-09-21T08:32:26Z

@NthPortal it actually can:
scala> object as {
     |   def unapply[A](a: A) = (a, a)
     | }
// defined object as

scala> Some(1) match { case a as Some(x) => (a, x) }
val res2: (Some[Int], Int) = (Some(1),1)
Recommending the use of this operator (which would be added to Predef) and deprecating @ would be a nice way of simplifying the language.

As much as I like implementing @/as in the userland, I am worried about the cost of tuple instantiation.

nafg · 2020-09-21T08:51:10Z

I'm pretty sure named extractors plus value classes allows you to do it in a way that avoids the boxing

…

On Mon, Sep 21, 2020, 4:32 AM Tamer Abdulradi ***@***.***> wrote: @NthPortal <https://github.com/NthPortal> it actually can: scala> object as { | def unapply[A](a: A) = (a, a) | }// defined object as scala> Some(1) match { case a as Some(x) => (a, x) }val res2: (Some[Int], Int) = (Some(1),1) Recommending the use of this operator (which would be added to Predef) and deprecating @ would be a nice way of simplifying the language. As much as I like implementing @/as in the userland, I am worried about the cost of tuple instantiation. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9829 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUBVQ7LFWLQ4IXWXXGLSG4FSTANCNFSM4RS4MP7Q> .

odersky · 2020-09-21T09:53:01Z

@LPTK It's interesting that one could define as as an extractor in that way. But it still does not solve the problem how to get capitalized names as binders.

sjrd · 2020-09-21T10:40:45Z

TBH, I find the capitalized names as binders a fringe use case, bordering on abuse of the feature. Not as bad as abstract case classes, but still.

But anyway, it doesn't matter. There's one thing that as-in-user-land or even my initial & proposal does not cover, and which is much more common: they don't refine the type of the binder. So in something like:

val tree: Tree = ???
tree match {
  case Apply(sel & Select(_, _)) =>
    sel.qual // does not compile: sel is a Tree, not a Select
}

and I don't think there is any way to either a) implement that in user-space nor b) correctly specify with a language-defined commutative &. To have this behavior, the binder must be non-commutative.

So I'm afraid we do need the concept of binder as defined in the language.

LPTK · 2020-09-21T12:28:19Z

@sjrd good point. You can always write Apply((sel: Select) as ...), but it is more verbose than with @.

I don't think there is any way to [...] b) correctly specify with a language-defined commutative &

Given a pattern A(...as) & B(...bs), couldn't you look at the input types T_A and T_B of the respective extractors A and B (for a pattern variable A = v, it would be T_A = Any) and then type check the ...as and ...bs subpatterns based on applying each extractors to a scrutinee of type T_A & T_B?

lihaoyi · 2020-09-21T13:12:40Z

I personally don't really like the keyword as, due to the somewhat unclear left-right order between the pattern thing being bound. Perhaps it's my personal experience speaking, but I'm very used to xxx as yyy binding the name yyy from Python, where this is front-and-center in the language's import/try-except/with-block syntax, and here it's the other way around. Python's PEP622 uses the := walrus operator for this same thing, which makes it very clear that the LHS is the name being assigned. I suppose Scala's equivalent would be using the = or <- operators which currently bind names to the left.

djspiewak · 2020-09-21T14:01:46Z

I am worried about the cost of tuple instantiation.

Pattern matching is already prohibitively slow for any code which is sensitive to allocations, so I'm not sure that we need to worry too much about adding a single layer of boxing in this case.

I'm worried more about the interaction between this feature and tableswitch, which currently works just fine using @, but would break the optimization if it were not a primitive.

bilal-fazlani · 2020-09-21T14:27:25Z

I like this proposal. From perspective of explaining scala pattern matching to new people, 'as' makes more sense than '@'

odersky · 2020-09-21T14:27:25Z

There's already a discussion in #9837 about the order of the operands of as. In a nutshell: there's precedent for both orders. Since one of the main reasons of the proposal is to reinforce learning in conjunction with given instances, the order is determined to be what it is in this proposal.

prolativ · 2020-09-21T15:34:26Z

Actually couldn't we simply have syntax like

case foo: Foo(_) => ...

by analogy to

case foo: Foo => ...

?

tabdulradi · 2020-09-21T15:38:06Z

The syntax is ambiguous if you have Foo.unapply defined Edit: Actually scratch that. What I mean saying is ambiguous if `Foo` itself is a defined value you want to match against Edit 2: To clarify what I meant above: ``` type Foo = Int val Foo = 42 42 match { case foo @ Foo => println("foo the value") case foo: Foo => println("foo the type") } ``` Cases above would be ambiguous if removed `@` syntax in favor just `:`

…

On Mon, Sep 21, 2020 at 4:34 PM Michał Pałka ***@***.***> wrote: Actually couldn't we simply have syntax like case foo: Foo(_) => ... by analogy to case foo: Foo => ... ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9829 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFRBVTWG46OGQYPIR6GCQ3SG5XBJANCNFSM4RS4MP7Q> .

som-snytt · 2020-09-21T16:21:15Z

Because of the mixed precedents for order, there is a danger that a beginner might write their patterns as-backward.

prolativ · 2020-09-22T08:23:32Z

If we can't reuse :, what about =?
That would quite nicely go with the syntax for value definitions.

case class Foo(i: Int)
object Foo

val fooInstance: Foo = new Foo(1)
val fooObject = Foo

x match {
    case fooInstance: Foo => ...
    case fooObject = Foo => ...
}

val someString = Some(s) = Some("xyz")

for {
    foo = Foo(i) <- Some(Foo(10))
} println(foo.toString + i)

for {
    case someInt = Some(_) <- Seq(Some(10), None, Some(5))
} yield someInt

The only problem I can see for now would be with patterns like

list match {
    head = hd :: tail => ...
}

if we decide to change precedence of bindings in patterns.

sjrd · 2020-09-22T08:29:07Z

I don't think there is any way to [...] b) correctly specify with a language-defined commutative &

Given a pattern A(...as) & B(...bs), couldn't you look at the input types T_A and T_B of the respective extractors A and B (for a pattern variable A = v, it would be T_A = Any) and then type check the ...as and ...bs subpatterns based on applying each extractors to a scrutinee of type T_A & T_B?

Hum, perhaps, yes. I can't convince myself either that it would indeed work or that it wouldn't. If it works, that would be very nice!

vasily-kirichenko · 2020-09-22T10:22:19Z

I find F#'s syntax, where the order of pattern and as is reverted is more natural and easier to read. In Scala it would look like this:

x match 
    case Success(x, in1) as s => ...
    case Failure(_, in1) as f => ...

  e match
    case (hd :: tl as xs, y) => ...

Why it's better? Because patterns are placed immediately after case which makes reading the whole match a lot easier than when the first thing you see (and have to skip) is a local binding, which does not bring any information in understanding the whole match, which is somewhat similar to the function definition in C-family languages, where return type obfuscates signature: public MySuperUsefulType foo() {}, you have to skip the return type to find the function name, it's hard.

jdegoes · 2020-09-22T13:26:03Z

@odersky Big 👍 from me given it's a soft keyword, and the pedagogical benefits of aligning this with as in givens are undeniable and significant.

Fix #9829: Allow `as` in place of `@` for pattern bindings

noresttherein · 2020-09-25T10:57:54Z

Can I ask if as is becoming a keyword only in the context of pattern matching, or a general reserved word? I am very worried about new scala's claiming quite a bit of new keywords, especially that no effort is made to use less common terms. This is a serious issue for libraries - the new keywords are likely widely used because they are so natural in DSL contexts.

tabdulradi · 2020-09-25T11:26:44Z

Can I ask if as is becoming a keyword only in the context of pattern matching, or a general reserved word? I am very worried about new scala's claiming quite a bit of new keywords, especially that no effort is made to use less common terms. This is a serious issue for libraries - the new keywords are likely widely used because they are so natural in DSL contexts.

Check #9829 (comment)

Yes, as can stay a soft keyword. It would be interpreted as a binder only when used as an infix operator in patterns.

odersky closed this as completed in 026be41 Sep 24, 2020

odersky added a commit that referenced this issue Sep 24, 2020

Merge pull request #9837 from dotty-staging/fix-#9829

959cab4

Fix #9829: Allow `as` in place of `@` for pattern bindings

rossabaker mentioned this issue Jan 29, 2021

Deprecate as for withContext http4s/http4s#4290

Closed

diesalbla mentioned this issue Jan 30, 2021

Functor: rename the as operator. typelevel/cats#3755

Closed

Proposal: Change @ to as #9829

Proposal: Change @ to as #9829

Comments

odersky commented Sep 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

som-snytt commented Sep 19, 2020

Uh oh!

sjrd commented Sep 19, 2020

Uh oh!

odersky commented Sep 19, 2020

Uh oh!

odersky commented Sep 19, 2020

Uh oh!

julienrf commented Sep 19, 2020

Uh oh!

odersky commented Sep 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LPTK commented Sep 19, 2020

Uh oh!

He-Pin commented Sep 19, 2020

Uh oh!

mpilquist commented Sep 20, 2020

Uh oh!

odersky commented Sep 20, 2020

Uh oh!

djspiewak commented Sep 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

som-snytt commented Sep 20, 2020

Uh oh!

odersky commented Sep 20, 2020

Uh oh!

djspiewak commented Sep 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

odersky commented Sep 20, 2020

Uh oh!

Sciss commented Sep 20, 2020

Uh oh!

som-snytt commented Sep 20, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nafg commented Sep 21, 2020 via email

Uh oh!

NthPortal commented Sep 21, 2020

Uh oh!

LPTK commented Sep 21, 2020

Uh oh!

tabdulradi commented Sep 21, 2020

Uh oh!

nafg commented Sep 21, 2020 via email

Uh oh!

odersky commented Sep 21, 2020

Uh oh!

sjrd commented Sep 21, 2020

Uh oh!

LPTK commented Sep 21, 2020

Uh oh!

lihaoyi commented Sep 21, 2020

Uh oh!

djspiewak commented Sep 21, 2020

Uh oh!

bilal-fazlani commented Sep 21, 2020

Uh oh!

odersky commented Sep 21, 2020

Uh oh!

prolativ commented Sep 21, 2020

Uh oh!

tabdulradi commented Sep 21, 2020 via email • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

som-snytt commented Sep 21, 2020

Uh oh!

prolativ commented Sep 22, 2020

Uh oh!

sjrd commented Sep 22, 2020

Uh oh!

vasily-kirichenko commented Sep 22, 2020

Uh oh!

Proposal: Change `@` to `as` #9829

Proposal: Change `@` to `as` #9829

odersky commented Sep 19, 2020 •

edited

Loading

odersky commented Sep 19, 2020 •

edited

Loading

djspiewak commented Sep 20, 2020 •

edited

Loading

djspiewak commented Sep 20, 2020 •

edited

Loading

som-snytt commented Sep 20, 2020 •

edited

Loading

tabdulradi commented Sep 21, 2020 via email •

edited

Loading