Allow currency symbols in identifiers #48
Conversation
This commit reserves the [zZ] and [sS] suffixes for Byte and Short literals, respectively. These work exactly like Long literals, which were already denoted with [lL]. For example, you can say: val zero = 0Z val bytes = List(23Z, 23Z, 0Z, 0Z, 111Z, -54Z, 19Z, 17Z) This commit does not permit literal unsigned bytes, so 255Z and 0xffZ are not legal. The choice of Z may seem strange, but B will not work for hex constants (0x10B would be ambiguous) so Z seemed like a good choice.
This adds a flag called `-Zirrefutable-generator-patterns` which changes
desugaring of code like the following:
for {
(a, b) <- List(1 -> 'a', 2 -> 'b')
(c, d) <- List(3 -> 'c', 4 -> 'd')
} yield (a + c, b + d)
Which previously would turn into something like:
List(1 -> 'a', 2 -> 'b').withFilter {
case (a, b) => true
case _ => false
}.flatMap {
case (a, b) =>
List(3 -> 'c', 4 -> 'd').withFilter {
case (c, d) => true
case _ => false
}.map {
case (c, d) =>
(a + c, b + d)
}
}
With this new flag, it only becomes:
List(1 -> 'a', 2 -> 'b').flatMap {
case (a, b) =>
List(3 -> 'c', 4 -> 'd').map {
case (c, d) =>
(a + c, b + d)
}
}
Which creates a few benefits:
1. We don't have to do a useless call to withFilter
2. We can use patterns on things without withFilter
3. Things don't silently disappear when patterns are wrong
We assume patterns are exhaustive when desugaring with `-Zirrefutable-generator-patterns` but we should still emit a warning if we think they might not be.
Add support for literal Byte and Short values.
Allow primes at the end of identifiers.
|
This wasn't massively complicated... |
|
Consider adding at least one test that proves they used to be forbidden and now are allowed? |
|
Good call. It's highlighted a parsing issue with combining currency symbols and other symbols in the same identifiers which I'll need to fix. |
|
Can one of the admins verify this patch? |
|
add to whitelist |
…tterns Conflicts: bincompat-forward.whitelist.conf src/compiler/scala/tools/nsc/settings/ScalaSettings.scala
…atterns Add flag to disable withFilter pattern desugaring
Example usage:
trait =!=[C, D]
implicit def neq[E, F] : E =!= F = null
@annotation.implicitAmbiguous("Could not prove ${J} =!= ${J}")
implicit def neqAmbig1[G, H, J] : J =!= J = null
implicit def neqAmbig2[I] : I =!= I = null
implicitly[Int =!= Int]
Which gives the following error:
implicit-ambiguous.scala:9: error: Could not prove Int =!= Int
implicitly[Int =!= Int]
^
Better than what was previously given:
implicit-ambiguous.scala:9: error: ambiguous implicit values:
both method neqAmbig1 in object Test of type [G, H, J]=> Main.$anon.Test.=!=[J,J]
and method neqAmbig2 in object Test of type [I]=> Main.$anon.Test.=!=[I,I]
match expected type Main.$anon.Test.=!=[Int,Int]
implicitly[Int =!= Int]
^
This is where our additions to scala-library.jar will go. The current content is the implicitAmbiguous annotation. I seemed to have made the right changes to make the REPL, the test classpath and scala-dist to work. I'm not sure if there's anything else we need but I also inserted references to typelevel where library was also referenced, just in case.
…otation Add an @implicitAmbiguous annotation
This commit adds a syntax for type functions that mirrors the
existing syntax for value functions. The underlying representation
for these types uses type projections, and is exactly the same
as those produced by the ({type L...})#L syntax.
Here are some examples:
[x] => Either[String, x]
[-x, +y] => (x, Int) => y
[y, x] => Map[x, y]
[x[_]] => x[Double]
This commit also changes how these types are pretty-printed, to
ensure that the type the user is shown matches the type they
would specify.
There's an interesting wrinkle around type lambda currying. It
was already possible to nest type lambdas, but this syntax makes
it much easier to do. However, these types generally don't work
properly, so they should be avoided.
(This is a squashed version of the commits from the v1 branch.)
update documentation for ENSIME
|
Just as a heads up if these sort of changes want to find their way upstream, we ask that the spec is updated in the same PR as the implementation. That was a big part of the motivation to markdown-ize it and bring it into |
|
Thanks, Jason. When I get round to fixing this properly (it's got various On 2 October 2014 06:51, Jason Zaugg notifications@github.com wrote:
Jon Pretty | @propensive |
If you wish to use currency symbols in Scala identifiers, use the -Zcurrency-symbols flag. Currency symbols behave in the same way as Unicode mathematical or "other" symbols. Treatment of the dollar sign (`$`) is unchanged.
|
This should be ready to go. Could someone (maybe @puffnfresh?) give it a quick review and press the big green button? |
|
If you would like to resurrect this issue/PR please rework it as a PR against Lightbend Scala 2.12.x (ie. scala/scala). |
|
Maybe if I find time later... ;) What was the status of the identifiers-with-primes change? Could these two be rolled into the same PR? |
|
I'm wiping the slate and starting again with a new policy around inclusion (expect an announcement soon). The primes as identifiers change isn't going to be in the 2.12.0-RC1 release. It would make sense to combine that change with this one and submit both upstream at that the same time. |
No description provided.