The @alpha notation

[soronpo]

To have both names accessible from Scala with @aka, it could possibly just be a static macro annotation that duplicates the def signature and calls one from the other. So if such macro annotations will be possible in Scala 3.x, we get it for free.

[sideeffffect]

my 2 bikeshedding cents:

• I really like the idea that it’s the alphanumeric name that should be cannonical
• @symbol("...") is probably better than @aka("..."), because it emphasizes that it’s for symbolic names of members; seeing “aka” doesn’t immediately suggest “Also Known As” – being lowercase doesn’t help
• @targetName("...") is probably better than @bytecodeName("..."), because Scala has other targets besides JVM bytecode, like LLVM bitcode or JavaScript
• if we can have more than 1 annotation, it would be better to separate the concern of symbol and targetName

This is how it would look:

trait Monoid[A] {
  extension(self: A)
    @symbol("++")
    def combine(that: A): A

  def empty: A
}

def fn(a: Any)
@targetName("fnT")
def fn[T](t: T)

@symbol("*>") @targetName("starRight")
def productR[F[_], A, B](fa: F[A], fb: F[B]): F[B]

[sideeffffect]

On the other hand, I understand the argument that allowing both alphanumeric and symbolic name for the same method is giving “too much freedom” to the library author which would cause “mess” for the users of that library.
From that point of view, Scala should force library authors to pick either an alphanumeric or symbolic name for a particular method. While requiring that symbolic name still has an alpha label for the purposes of documentation and googling. But that alpha name wouldn’t be usable to call the method.

[morgen-peschke]

@sideeffffect

On the other hand, I understand the argument that allowing both alphanumeric and symbolic name for the same method is giving “too much freedom” to the library author which would cause “mess” for the users of that library.

I really appreciated that freedom when /: was still hanging around, and it’s not like there’s a way to prevent the inclusion of both the symbolic and alphanumeric versions.

It’s just a question of how easy that should be to implement, and I would tend to err on the side of making it easier for library maintainers to make it easy for library users. I don’t really see how providing a named alternative to an operator could hurt ease of use.

[curoli]

Is Scala the only JVM language allowing, say, + as a method name? It would be a pity if there was another language out there that could use + but doesn’t see it in a Scala class.

[LPTK]

Good point. Kotlin allows the standard operators to be “overloaded”, and a + b is seen as a.plus(b). As I said above, it’d be nice if we did the same at least for standard operators.

[sjrd]

@odersky

It would be good if other members of the SIP committee would weigh in here since the opposition to providing dual names was quite strong.

Your post conveys very well my opinion on the topic.

[rgwilton]

I agree that alphanumeric names should be the default for any non-standard operator.

I prefer @symbol, or perhaps even @symbolic to make it clear that a secondary symbolic name can be provided, but a second alphanumeric name cannot be provided.

[bjornregnell]

I like the proposal from @sideeffffect to separate the concerns of dual names e.g. @symbol and encoding at the low level e.g. @targetName . If there is restrictions on symbolic names then I think “standard” operators such as + - * should be an exception so that classes like Complex and Point and Time etc can be defined without strange/awkward syntax/annotations/imports.

I agree that it is good to be more “opinionated” and less “liberal/pragmatic” after learning from Scala 2 to gain increased regularity/consistency in Scala 3, but I think we here need to strive for a balance point in the middle (lagom as we say in Sweden for just right ) and it should not go “extreme” on the either side.

After all it is anyhow possible to create incomprehensible method names using only letters… Idioms are nice help but contextual and not law.

[bishabosha]

Duelling dual names could be resolved by using export with rename:

class C { def addAll() = () ; export this.{addAll => ++=} }

seems a shame that export is illegal from this

[Jasper-M]

@odersky

Thanks for the input! We discussed the @alpha annotation a while back in the SIP meetings. No formal vote was taken but the tendency echoed your sentiment: @alpha should remain optional for symbolic operators.

I’ll change the docs to remove the critical sentence and put the warning under a flag.

Whatever brilliant annotation or set of annotations and ingenious semantics result out of this discussion, I hope this statement still stands. Apart from the beginner-argument, let’s not forget that (hopefully) by far the most code is application code, not library code. IMHO when writing application code you get virtually no benefit from having to add extra annotations, only useless boilerplate and possibly confusion.

[sjrd]

That has already happened: https://github.com/lampepfl/dotty/pull/10093

[kai]

@bishabosha

seems a shame that export is illegal from this

This can be worked around with a proxy object:

class C { outer =>
  export proxy.{addAll => ++=}
  object proxy {
   export outer.addAll
  }
}

It ought to really work on this. though, as I don’t see a reason for it not to. I’ve opened an issue sometime ago to track this: Cannot create renamed copies of members of `this` using `export` · Issue #9704 · lampepfl/dotty · GitHub

[kai]

@sideeffffect

if we can have more than 1 annotation, it would be better to separate the concern of symbol and targetName

The suggestion to add a targetName parameter to @symbol annotation was because there would be no way to add such an annotation to the generated operator method since it has no symbol.

It could be useful to annotate both the original symbol AND the generated symbol with their own @targetName annotations, e.g. to support bytecode-ambiguous set of overloads for both the alphanumeric and the symbolic name.

Though I guess you could expand the symbols into explicit defs in that case and annotate them, but that could also make you lose some niceties such as an IDE showing the original function instead of the alias — however, if export gains an ability to add annotations, these advanced use cases could be implemented using annotated export’s, for which an IDE could reference the original definitions, instead of exported, too.

[dwalend]

I’ve found it is very rare but not vanishingly rare that I write code or read code where symbolic notation helps. I think that @symbol - opt in - would be a better option than @alpha - opt out. And I’d like to be able to import the symbols separate from the rest of the library.

At work we write code for a scala project that is 12 years old. We plan for another 12. The rule we’ve adopted is “if the symbol is in a text book that we’ve all used then it’s OK. Otherwise use words.” In my own hobby code I’ve found that I rarely use a given library to the extent the authors’ expect. One of Scala’s great strength is the ability to sample from multiple libraries as needed. I would never want to deal with code that relied on two libraries competing for the same symbol, or - possibly worse - similar-looking slightly-different symbols.

The important but rare exception is numerics. Symbols from Spire mostly make sense. Symbols for graphs and processes were confusing. Symbols for general data structures didn’t capture the nuances of words. There are often better options; I no longer use + to chain strings together because s"" seems universally better.

Encouraging library authors to always supply names, and - when it seems wise to them - to supply symbols - seems a better choice that leaves the rest of us the freedom to follow them as far as we choose. Maybe something that builds on the idea of import renaming in a standard way - a standard namespace to import for a library’s symbols - might serve developers’ needs well while letting library authors encourage us to follow their path.

Thanks,

David

[soronpo]

Symbols also set associativity and precedence. It’s not something that can be accomplished with pure names.

[odersky]

There’s now a PR to rename @alpha to @targetName, with the added power that you can use @targetName to avoid conflicting method definitions that have the same erasure.

Rename @alpha to @targetName