another matter of syntax

[Paul Phillips]

[Everything in here is paulp's personal thoughts, does not represent
scala, typesafe, or anything else etc etc do not taunt happy fun ball
etc.]

While we're sort of on the subject.

The relatively well-known collision in the land of the underscores is
between existentials and type constructors, such that

def f[CC[_]]

means one thing and

def f[CC[_] <: Traversable[_]]

doesn't mean what people usually think it means. There are more,
especially once one journeys into the land of "not yet implemented."
(I forget if there are any more if we restrict ourselves to that which
exists.)

scala> def f[T <: Singleton, U, V, W](x: T, y: U, v: V, w: W) = 1
f: [T <: Singleton, U, V, W](x: T, y: U, v: V, w: W)Int

scala> val x = "bippy"
x: String = bippy

scala> f(x, Set, Iterable, Traversable)
<console>:10: error: inferred type arguments
[String,scala.collection.immutable.Set.type,collection.Iterable.type,collection.Traversable.type]
do not conform to method f's type parameter bounds [T <:
Singleton,U,V,W]
f(x, Set, Iterable, Traversable)
^

How sad for us. It won't infer x.type for x despite our
encouragement, so we will have to supply it - and that means we have
to supply all the type arguments, however crazy those other types
might be.

// not that crazy in this case, but still
scala> f[x.type, Set.type, Iterable.type, Traversable.type](x, Set,
Iterable, Traversable)
res1: Int = 1

WOULDN'T you like it if you could do one of these (or roll your own syntax)

f[x.type,_,_,_](x, Set, Iterable, Traversable)
f[x.type,?,?,?](x, Set, Iterable, Traversable)
f[T=x.type](x, Set, Iterable, Traversable)

So what's the problem with mr. underscore there? For that one we have
to enter another hypothetical land. Wouldn't it ALSO be nice if you
could do this:

scala> def f[T, U, V] : ((T, U, V)) = ???
f: [T, U, V]=> (T, U, V)

// Not an actual transcript
scala> def g = f[String, Int, _]
g: [V]=> (String, Int, V)

Maybe you see the problem. What does the underscore mean? Is it a
"over to you, type inferencer" parameter, or does it represent partial
application?

What about this:

case x: Foo[tv[_]] => ...

Does that mean tv is a type constructor, so I can use tv[Int] on the
other side? Or does it mean tv is something previously parameterized
and I don't care what on?

I think people who aren't me, like adriaan, have more examples.

One reason I have this on my mind is that I want to fix Array
matching. Right now all AnyRef derived Arrays match on Array[AnyRef],
even though only Array[AnyRef] is actually an Array[AnyRef] - in scala
anyway. To fix this, I need syntax which doesn't exist:

def f(x: Any) = x match {
// should only match Array[AnyRef], so how to match all of them?
case _: Array[AnyRef] =>
// like this, in principle
case _: Array[t <: AnyRef] => ...
}

This is separate from the _/? issue above, but I'm throwing it all out
there in the hopes that more people thinking about things will lead to
a better outcome.

[Erik Osheim]

On Fri, Mar 16, 2012 at 09:59:29AM -0700, Paul Phillips wrote:
> So what's the problem with mr. underscore there? For that one we have
> to enter another hypothetical land. Wouldn't it ALSO be nice if you
> could do this:
>
> scala> def f[T, U, V] : ((T, U, V)) = ???
> f: [T, U, V]=> (T, U, V)
>
> // Not an actual transcript
> scala> def g = f[String, Int, _]
> g: [V]=> (String, Int, V)
>
>
> Maybe you see the problem. What does the underscore mean? Is it a
> "over to you, type inferencer" parameter, or does it represent partial
> application?
>
> What about this:
>
> case x: Foo[tv[_]] => ...
>
> Does that mean tv is a type constructor, so I can use tv[Int] on the

This is the one I vote for, since it seems to me like the most obvious
behavior, and also one that I would like to have to avoid type
projections like ({type L[X,Y] = ...})#L.

That said, being able to do something like "[A,B] => Tuple3[A, A, B]"
(interpreted as ({type L[A,B] = Tuple3[A,A,B]})#L of course) would be
even nicer.

The other forms have their uses as well though. It seems like the best
way to resolve this would be to reserve a few more symbols to mean
different things (for instance "?" like you suggest).

But I will defer to people like Adriaan who've probably thought a lot
harder about this than I have. [1]

-- Erik

[1] Although I did write this nifty compiler plugin:
https://github.com/non/kind-projector

[Daniel Sobral]

On Fri, Mar 16, 2012 at 13:59, Paul Phillips <pa...@improving.org> wrote:
>  f[x.type,?,?,?](x, Set, Iterable, Traversable)

There's a plugin for this syntax, isn't there?

--
Daniel C. Sobral

I travel to the future all the time.

[martin odersky]

On Array matching, I believe that logically, the following should work:

case _ : Array[t] forSome { type t <: AnyRef }

Right now it doesn't, but that's probably something we should fix
first. I mean, no use allowing a special case if the desugaring of
that special case into the general case gives a syntax error.

Cheers

-- Martin

[Paul Phillips]

On Sat, Mar 17, 2012 at 5:19 AM, martin odersky <martin....@epfl.ch> wrote:
> On Array matching, I believe that logically, the following should work:
>
>  case _ : Array[t] forSome { type t <: AnyRef }
>
> Right now it doesn't, but that's probably something we should fix
> first.  I mean, no use allowing a special case if the desugaring of
> that special case into the general case gives a syntax error.

This morning I was going to say "that's a good point" but now it seems
somewhat undermined by the proposal to take this syntax away from us.

I wonder if there is some way to quantify all the pain it will bring
in the world of bug reports, answering questions, etc. Like people
don't leave enough details out already, now the first round of
followups has to include "did you import any language features?"