Most obscure Scala feature ever...?

[Seth Tisue]

Today I hit this:

scala> val (xs: List[scala.Int], _) = (List(5), 6)
<console>:1: error: ']' expected but '.' found.
val (xs: List[scala.Int], _) = (List(5), 6)
^

after an hour or so of coming up empty on IRC and in JIRA, thinking it
must be a bug but wanting to rule out other explanations, I eventually
found out about "type variable patterns" from SLS 8.2 and 8.3, and that
led me here:

http://stackoverflow.com/questions/7413671/scala-pattern-match-problem-with-fully-qualified-classnames-in-parameterization

Wow, so Scala has "type variable patterns". I had no idea, and neither
did a whole roomful of Scala programmers on IRC (*). All of the top
Google hits on this are either just on the spec, or are on people who
hit the same parsing issue I did. There are no JIRA issues that mention
"type variable pattern" except SI-4628 which doesn't really count (it's
about a minor spec update).

Is this the most obscure Scala feature ever...?

Does anyone use it...?

It'd be nice if the parser gave a better error message in this case.

(*) Except Tom Switzer, who says he used this in the Precog codebase.
Of course, where else? I invite him to reply with details.

--
Seth Tisue | Northwestern University | http://tisue.net
developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Tom Switzer]

So, here is a really simple contrived example. Not useful, but perhaps showing the feature's utility.

https://gist.github.com/tixxit/7551058

Here are some examples in the Precog code-base:

https://github.com/precog/platform/blob/master/yggdrasil/src/main/scala/com/precog/yggdrasil/table/Column.scala#L150

https://github.com/precog/platform/blob/master/mimir/src/main/scala/com/precog/mimir/ArrayLib.scala#L153

And a whack-load in here:

https://github.com/precog/platform/blob/master/yggdrasil/src/main/scala/com/precog/yggdrasil/table/cf/Util.scala

In these cases, they're all used so that we can instantiate instances of things that require a type parameter that we got from pattern matching & type variables.

Here is another example that, perhaps, doesn't need the type variable, but let's us write explicit types inside of a pattern match:

https://github.com/precog/platform/blob/master/yggdrasil/src/main/scala/com/precog/yggdrasil/nihdb/SegmentsWrapper.scala#L73

So, it could be used to make things more readable, or help with type inference when it fails.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Tom Switzer]

Anyways, the point is sometimes we get a type (via a type parameter) we didn't have before a pattern match (for instance, when we have an ADT where only some leaves have type parameters - like in the gist I posted). It is useful to be able to talk about that type, even if we don't know what it is. Scala does this for you, behind the scenes, a lot. But if type inference fails (eg. you want to use collection.breakOut and force result to Vector[a]) or you need to use the type in a situation where type inference couldn't know about it (eg. creating a new anonymous instance of a paramaterized trait), then type variables let us do this.

[Jason Zaugg]

On Tue, Nov 19, 2013 at 8:19 PM, Seth Tisue <se...@tisue.net> wrote:

Today I hit this:

scala> val (xs: List[scala.Int], _)  = (List(5), 6)
<console>:1: error: ']' expected but '.' found.
       val (xs: List[scala.Int], _)  = (List(5), 6)
                          ^

after an hour or so of coming up empty on IRC and in JIRA, thinking it
must be a bug but wanting to rule out other explanations, I eventually
found out about "type variable patterns" from SLS 8.2 and 8.3, and that
led me here:

And now you understand the phrasing of this familiar unchecked warning:

scala> List[Any]() match { case _: List[String] => case _ => }

<console>:8: warning: non-variable type argument String in type pattern List[String] is unchecked since it is eliminated by erasure

              List[Any]() match { case _: List[String] => case _ => }

                                          ^

-jason 

[martin odersky]

On Tue, Nov 19, 2013 at 8:19 PM, Seth Tisue <se...@tisue.net> wrote:

Today I hit this:

scala> val (xs: List[scala.Int], _)  = (List(5), 6)
<console>:1: error: ']' expected but '.' found.
       val (xs: List[scala.Int], _)  = (List(5), 6)
                          ^

after an hour or so of coming up empty on IRC and in JIRA, thinking it
must be a bug but wanting to rule out other explanations, I eventually
found out about "type variable patterns" from SLS 8.2 and 8.3, and that
led me here:

http://stackoverflow.com/questions/7413671/scala-pattern-match-problem-with-fully-qualified-classnames-in-parameterization

Wow, so Scala has "type variable patterns".  I had no idea, and neither
did a whole roomful of Scala programmers on IRC (*).  All of the top
Google hits on this are either just on the spec, or are on people who
hit the same parsing issue I did.  There are no JIRA issues that mention
"type variable pattern" except SI-4628 which doesn't really count (it's
about a minor spec update).

Is this the most obscure Scala feature ever...?

Does anyone use it...?

It'd be nice if the parser gave a better error message in this case.

Indeed. I would classify it as a bug. In fact, the parser should not issue an error at all, but simply parse the whole type.

Cheers

 - Martin

 

(*) Except Tom Switzer, who says he used this in the Precog codebase.
Of course, where else?  I invite him to reply with details.

--
Seth Tisue | Northwestern University | http://tisue.net
developer, NetLogo: http://ccl.northwestern.edu/netlogo/

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Prof. Martin Odersky
LAMP/IC, EPFL
Station 14, 1015 Lausanne, Switzerland
Tel: +41 21 693 6863

[Jason Zaugg]

On Tue, Nov 19, 2013 at 9:07 PM, martin odersky <martin....@epfl.ch> wrote:

On Tue, Nov 19, 2013 at 8:19 PM, Seth Tisue <se...@tisue.net> wrote:

It'd be nice if the parser gave a better error message in this case.

Indeed. I would classify it as a bug. In fact, the parser should not issue an error at all, but simply parse the whole type.

Agreed, that would be consistent with

   scala> Nil match { case scala.Nil => }

I've lodged a ticket: https://issues.scala-lang.org/browse/SI-7985

-jason

[Jason Zaugg]

On Tue, Nov 19, 2013 at 9:12 PM, Jason Zaugg <jza...@gmail.com> wrote:

Agreed, that would be consistent with

   scala> Nil match { case scala.Nil => }

I've lodged a ticket: https://issues.scala-lang.org/browse/SI-7985

And here's a patch:

  https://github.com/scala/scala/pull/3162/files

As a bonus, we can now support projections:

  scala> class a { type X = Int }

  defined class a

  scala> Array(1) match { case Array[a#X] => }

-jason

[martin]

That was quick! But I believe it might be better to attack the problem more at the root. The problem with the patch is that

  case Array[a[b]]

would still be rejected by the parser with the obscure error message. Why not just read a full type regardless and then inspect the resulting tree to see whether it represents a variable (lower-case) ident? That would be analogous to what we do with term ids, I believe.

Cheers

 - Martin

 

-jason

[Jason Zaugg]

On Tue, Nov 19, 2013 at 10:43 PM, martin <ode...@gmail.com> wrote:

That was quick! But I believe it might be better to attack the problem more at the root. The problem with the patch is that

  case Array[a[b]]

would still be rejected by the parser with the obscure error message. Why not just read a full type regardless and then inspect the resulting tree to see whether it represents a variable (lower-case) ident? That would be analogous to what we do with term ids, I believe.

Good idea, I've added a commit the PR that follows this suggestion.

-jason 

[Som Snytt]

That was still pretty amazing. I saw the PR first, then just read the email thread and experienced the weirdest déjà vu.

[Seth Tisue]

Y'all are awesome.