View bounds

[Heiko Seeberger]

Hi,

Some time ago there has been a discussion whether to deprecate view bounds in 2.10.

What's the status? Will that happen?

Thanks

Heiko

--

Heiko Seeberger
Twitter: @hseeberger

Blog: heikoseeberger.name

Company: Typesafe - The software stack for applications that scale
Author of "Durchstarten mit Scala, a tutorial-style Scala book"

[Heiko Seeberger]

Asking once more: What's the status of deprecating view bounds?

Thanks

Heiko

[martin odersky]

On Wed, Sep 12, 2012 at 7:57 AM, Heiko Seeberger <heiko.s...@gmail.com> wrote:

Asking once more: What's the status of deprecating view bounds?

I'd be in favor. What do others think? - Martin

 

Thanks

Heiko

On Sep 6, 2012, at 10:26 AM, Heiko Seeberger <heiko.s...@gmail.com> wrote:

Hi,

Some time ago there has been a discussion whether to deprecate view bounds in 2.10.

What's the status? Will that happen?

Thanks

Heiko

--

Heiko Seeberger
Twitter: @hseeberger

Blog: heikoseeberger.name

Company: Typesafe - The software stack for applications that scale
Author of "Durchstarten mit Scala, a tutorial-style Scala book"

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Roland Kuhn]

12 sep 2012 kl. 08:40 skrev martin odersky:

On Wed, Sep 12, 2012 at 7:57 AM, Heiko Seeberger <heiko.s...@gmail.com> wrote:

Asking once more: What's the status of deprecating view bounds?

I'd be in favor. What do others think? - Martin

Ouch, then we’d have to change one (1) occurrence in our not-so-small code base ;-) (and that occurrence is not yet released)

I’d say: fire away!

Regards,

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[Rex Kerr]

On Wed, Sep 12, 2012 at 2:40 AM, martin odersky <martin....@epfl.ch> wrote:

On Wed, Sep 12, 2012 at 7:57 AM, Heiko Seeberger <heiko.s...@gmail.com> wrote:

Asking once more: What's the status of deprecating view bounds?

I'd be in favor. What do others think? - Martin

 

If the deprecation message could state how to change to a context bound, sure.

Your example from before can probably be used almost verbatim:

"""
A method with a view bound:

def foo[T <% Ordered[T]](x: T, y: T) = x < y

To get rid of the view bound, define a type alias

 type OrderedView[T] = T => Ordered[T]

and rewrite foo to:

def foo[T: OrderedView](x: T, y: T) = x < y

"""

[Jason Zaugg]

If the view bound is on a top level class, one would have to create a
package object to house the type def. I can imagine this being a bit
confusing, as many people haven't created package objects before.
Furthermore, they would introduce the type into namespace of the
package, which probably isn't desirable.

I would almost prefer to suggest a rewrite with an implicit parameter
of A => B. We don't even have to desugar the other bounds, as one of
the little known features of Scala 2.10 is that you can mix implicit
bounds with an implicit parameter list.

scala> class C[A: Ordering](implicit x: A => String)
defined class C

scala> new C[Int]()()
<console>:9: error: not enough arguments for constructor C: (implicit
evidence: Ordering[Int], implicit x: Int => String)C[Int].
Unspecified value parameters evidence$1, x.
new C[Int]()()
^

-jason

[Rex Kerr]

On Wed, Sep 12, 2012 at 3:36 AM, Jason Zaugg <jza...@gmail.com> wrote:

On Wed, Sep 12, 2012 at 9:02 AM, Rex Kerr <ich...@gmail.com> wrote:
> On Wed, Sep 12, 2012 at 2:40 AM, martin odersky <martin....@epfl.ch>
> wrote:

> If the deprecation message could state how to change to a context bound,
> sure.
>
> Your example from before can probably be used almost verbatim:
>
> """
> A method with a view bound:
>
> def foo[T <% Ordered[T]](x: T, y: T) = x < y
>
> To get rid of the view bound, define a type alias
>
>  type OrderedView[T] = T => Ordered[T]
>
> and rewrite foo to:
>
> def foo[T: OrderedView](x: T, y: T) = x < y
>
> """

If the view bound is on a top level class, one would have to create a
package object to house the type def. I can imagine this being a bit
confusing, as many people haven't created package objects before.
Furthermore, they would introduce the type into namespace of the
package, which probably isn't desirable.

I agree that there are complications, but if the justification for deprecation is that context bounds is what was wanted all along, and you can convert from view bounds to context bounds easily, then if you don't tell people about the alternate approach it seems to undermine the justification for deprecation.  Otherwise it's just, "We're going to make you write more boilerplate.  Fun, neh?"

(FWIW, if you only use it in one spot, the type alias is more boilerplate than the explicit implicit.)

  --Rex

[Jason Zaugg]

On Wed, Sep 12, 2012 at 10:46 AM, Rex Kerr <ich...@gmail.com> wrote:
> I agree that there are complications, but if the justification for
> deprecation is that context bounds is what was wanted all along, and you can
> convert from view bounds to context bounds easily, then if you don't tell
> people about the alternate approach it seems to undermine the justification
> for deprecation. Otherwise it's just, "We're going to make you write more
> boilerplate. Fun, neh?"
>
> (FWIW, if you only use it in one spot, the type alias is more boilerplate
> than the explicit implicit.)

Maybe the compiler error should link to a mini migration guide on
docs.scala-lang.org that describes the motivation for the change, the
options for how to update the code, and the tradeoffs.

-jason

[√iktor Ҡlang]

On Wed, Sep 12, 2012 at 8:40 AM, martin odersky <martin....@epfl.ch> wrote:

On Wed, Sep 12, 2012 at 7:57 AM, Heiko Seeberger <heiko.s...@gmail.com> wrote:

Asking once more: What's the status of deprecating view bounds?

I'd be in favor. What do others think? - Martin

Me too

 

 

Thanks

Heiko

On Sep 6, 2012, at 10:26 AM, Heiko Seeberger <heiko.s...@gmail.com> wrote:

Hi,

Some time ago there has been a discussion whether to deprecate view bounds in 2.10.

What's the status? Will that happen?

Thanks

Heiko

--

Heiko Seeberger
Twitter: @hseeberger

Blog: heikoseeberger.name

Company: Typesafe - The software stack for applications that scale
Author of "Durchstarten mit Scala, a tutorial-style Scala book"

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Jonas Bonér]

On Wed, Sep 12, 2012 at 8:40 AM, martin odersky <martin....@epfl.ch> wrote:
>
>

> On Wed, Sep 12, 2012 at 7:57 AM, Heiko Seeberger <heiko.s...@gmail.com>
> wrote:
>>
>> Asking once more: What's the status of deprecating view bounds?
>>
> I'd be in favor. What do others think? - Martin
>

+1

>>
>> Thanks
>> Heiko
>>
>> On Sep 6, 2012, at 10:26 AM, Heiko Seeberger <heiko.s...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> Some time ago there has been a discussion whether to deprecate view bounds
>> in 2.10.
>> What's the status? Will that happen?
>>
>> Thanks
>> Heiko
>>
>> --
>>
>> Heiko Seeberger
>> Twitter: @hseeberger
>> Blog: heikoseeberger.name
>> Company: Typesafe - The software stack for applications that scale
>> Author of "Durchstarten mit Scala, a tutorial-style Scala book"
>>
>>
>
>
>
> --
> Martin Odersky
> Prof., EPFL and Chairman, Typesafe
> PSED, 1015 Lausanne, Switzerland
> Tel. EPFL: +41 21 693 6863
> Tel. Typesafe: +41 21 691 4967
>

--
Jonas Bonér
Phone: +46 733 777 123
Home: http://jonasboner.com
Twitter: @jboner

[Josh Suereth]

At this point,  I'm terrified of adding anything to the compiler that isn't work/fixing already slated.

That said, I'd be for deprecation if we had a patch with significant test coverage!  

[Matthew Pocock]

Is it true that in every case that you have:

def foo[T <% Bar](x: T) = ???

that this is semantically identical with this?

def foo(x: T)(implicit T => Bar) = ???

If I've got the de-sugaring right, and every program expressed using T <% U can be re-written to a program that behaves the same way using an implicit T => U parameter, then I'd say deprecate <% and get the compiler to spit out the replacement equivalent implicit in the error message.

Matthew

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Josh Suereth]

It should be 100% true.  If not, then it's a bug.

[Seth Tisue]

On Wed, Sep 12, 2012 at 10:35 AM, Matthew Pocock
<turingate...@gmail.com> wrote:

> Is it true that in every case that you have:
>
> def foo[T <% Bar](x: T) = ???
>
> that this is semantically identical with this?
>
> def foo(x: T)(implicit T => Bar) = ???

nitpick: I think you mean
def foo[T](x: T)(implicit ev: T => Bar) = ???

where `ev` is some freshly generated identifier.

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

[Paul Phillips]

On Wednesday, September 12, 2012, Matthew Pocock wrote:

If I've got the de-sugaring right, and every program expressed using T <% U can be re-written to a program that behaves the same way using an implicit T => U parameter, then I'd say deprecate <% and get the compiler to spit out the replacement equivalent implicit in the error message.

The last time this came up:

  https://groups.google.com/d/msg/scala-sips/wP6dL8nIAQs/NQFNLGEpGoMJ

I asked how to translate this:

    scala> def f[K, V, T <% Map[K, V]](map: T, k: K) = map(k)

    f: [K, V, T](map: T, k: K)(implicit evidence$1: T => Map[K,V])V

Stefan impressively came up with this:

    scala> def f[K, V, T : ({ type L[X] = T => Map[K, V] })#L](map: T, k: K) = map(k)

I am not sure anyone is ready for the compiler to suggest that.

[Roland Kuhn]

[I thought about suggesting a type alias, but that does not help much]

The suggestion could also be to replace the bound by an explicitly mentioned evidence:

def f[K, V, T](map: T, k: K)(implicit ev: T => Map[K, V]): V

That does not look too bad? (or am I missing something?)

Regards,

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[Roland Kuhn]

… and since I was quite sure that I must be missing something, I had to try it out:

Welcome to Scala version 2.10.0-20120902-100908-5415272018 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_04).

Type in expressions to have them evaluated.

Type :help for more information.

scala> class A

defined class A

scala> implicit def fA(a: A) = Map(1 -> "1")

warning: there were 1 feature warnings; re-run with -feature for details

fA: (a: A)scala.collection.immutable.Map[Int,String]

scala> def f[K,V,T](map:T,key:K)(implicit ev: T => Map[K, V]) = map(key)

f: [K, V, T](map: T, key: K)(implicit ev: T => Map[K,V])V

scala> f(new A, 1)

res0: String = 1

[Paul Phillips]

On Wednesday, September 12, 2012, Roland Kuhn wrote:

def f[K, V, T](map: T, k: K)(implicit ev: T => Map[K, V]): V

That does not look too bad? (or am I missing something?)

No, it's fine; I was essentially responding to something which probably nobody said, that we can offer a context bounds replacement for view bounds uses.  We can offer an implicit parameter for sure.

[Rex Kerr]

That was me suggesting context bound suggestions.  I agree upon reflection that it is too tricky in the general case.  As a corollary, context bounds do not fully cover view bounds in an elegant way; sometimes it's awkward.  Still, reducing the number of weird symbols is a valuable enterprise.

  --Rex

[Simon Ochsenreither]

Any opinions/ideas/proposals/ideas on how to move this forward?

Maybe it makes sense to invite the wider ecosystem to comment on this issue?
Not sure if that makes sense or whether it we should take the usual approach of deprecating it, and then just wait and see how many people complain?)

Shall I file a bug to at least track the idea?

[Grzegorz Kossakowski]

On 30 June 2013 07:08, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Any opinions/ideas/proposals/ideas on how to move this forward?

Maybe it makes sense to invite the wider ecosystem to comment on this issue?
Not sure if that makes sense or whether it we should take the usual approach of deprecating it, and then just wait and see how many people complain?)

I think this thread shows that we have rather universal agreement on deprecating view bounds. We are missing a person who has time to deal with the whole deprecation process which in this case would include:

• writing a mini guide which includes rationale for deprecating view bounds and outlines migration strategies (examples discussed in this thread are a good start)
• write a code which warns about view bounds being used
• migrate our own code base so we don't have new deprecation warnings when compiling the library and the compiler

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[√iktor Ҡlang]

This also means deprecating the parts of the stdlib that uses view bounds

Cheers,

√

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

--

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

[Simon Ochsenreither]

Every journey into the compiler starts with a ticket.
Now we have one: https://issues.scala-lang.org/browse/SI-7629 :-)

[Simon Ochsenreither]

I pinged the Scala IDE mailing list regarding quick fixes and made a change to Parsers.scala to deprecate view bounds: https://github.com/soc/scala/compare/SI-7629-deprecate-view-bounds?expand=1

This is of course pretty straight-forward, but doing it in the parser means that it's happening too early to provide specific migration suggestions. What do people think? I have no issue digging deeper (considering that the REPL already shows the “desugared” variant anyway, so the code already exists), but if people say “I think this is perfectly fine” I have plenty of other things to spend my time on.

Opinions/suggestions/hints?

[Adriaan Moors]

Deprecation ftw!

Given `class Has[To] { type Conversion[From] = From => To }`

`def foo[T <% Int](x: T) = (x: Int)`

can be rewritten to:

`def foo[T: Has[Int]#Conversion](x: T) = (x: Int)`

--

[√iktor Ҡlang]

Or classless :)

type Has[T] = {type Conversion[R] = T => R}

[Rex Kerr]

It's a pity that `def foo[T: _ => Int](t: T)` doesn't work.  It ought to in analogy with partially applied functions.

As it is, it takes a lot of explaining before this looks like anything but a "we decided this was too easy so we're making your life harder!" kind of change.  Maybe that's the point, though?

  --Rex

[Adriaan Moors]

Yep! Direct syntactic support for type functions would be nice. Unfortunately, _'s semantic overloading budget was spent several times over (for full support for type functions, you'll also need to spend more syntax: one token for the type-level arrow, and figure out how to compactly specify kinds for the arguments)

[Paul Phillips]

On Sun, Aug 25, 2013 at 11:16 AM, Adriaan Moors <adriaa...@typesafe.com> wrote:

Yep! Direct syntactic support for type functions would be nice. Unfortunately, _'s semantic overloading budget was spent several times over (for full support for type functions, you'll also need to spend more syntax: one token for the type-level arrow, and figure out how to compactly specify kinds for the arguments)

It's not too late (well, I guess it is for you guys) to switch to ? for existential wildcards. You'll have to reclaim some punctuation someday, one way or another.

[Simon Ochsenreither]

Pull request with additional tests: https://github.com/scala/scala/pull/2909

IDE quick fix: https://groups.google.com/d/topic/scala-ide-dev/3aBzKPDJnlU/discussion (Requires compiler warning to work)

[Michael Slinn]

Has a decision been made regarding when support for view bounds might be removed?

[Adriaan Moors]

It's blocked by having tool support for rewriting code that's using them.

On Wed, Jun 17, 2015 at 8:15 AM, Michael Slinn <msl...@gmail.com> wrote:

Has a decision been made regarding when support for view bounds might be removed?

--

You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mike Slinn]

So view bounds are expected to remain deprecated but still available
until at least Scala 2.13, then.

[Rex Kerr]

In addition, there are new tests and patches that will remove some of the bugs and surprises in view bounds in 2.12.

Their long-term future is not entirely clear.

 --Rex

[Mike Slinn]

Interesting. So "view bounds v2" may cause view bounds to be
un-deprecated in 2.12. Any idea when there might be more clarity on this?

[Rex Kerr]

Clarity is elusive.  I think it's going to be a race between tooling that helps make them better, and tooling that helps make it easier to remove them (along with a sufficiently compelling alternative, if it is judged that one is needed).  For now I would approach them with caution, but if you really need them I'd use them anyway as the goal is to not just drop them without any support--so there should at least be some non-excruciating migration path.

  --Rex

On Wed, Jun 17, 2015 at 3:30 PM, Mike Slinn <msl...@gmail.com> wrote:

Interesting. So "view bounds v2" may cause view bounds to be un-deprecated in 2.12. Any idea when there might be more clarity on this?

[Adriaan Moors]

I'm not sure what Rex is referring to, but my default position is that view bounds remain on their way out. They will likely stay in the language for a few more years as we don't want to break source compatibility in the 2.x series over this.

We may move more quickly if said tools emerge and become common practice. That will also take time of course.

On Wed, Jun 17, 2015 at 3:30 PM, Mike Slinn <msl...@gmail.com> wrote:

Interesting. So "view bounds v2" may cause view bounds to be un-deprecated in 2.12. Any idea when there might be more clarity on this?

[Rex Kerr]

I am completely confused.  Do not listen to a thing I said.

I was thinking of views, not view bounds.

  --Rex

[Mike Slinn]

We are updating a lecture on ScalaCourses.com that currently says "view
bounds are deprecated, and here are the recommended alternatives". We
like to give students a heads-up of what to expect in future Scala
versions whenever possible.

ScalaCourses.com updates course material much more frequently that is
possible with a static medium like books or PDFs. We update the
transcripts rather quickly, then redo a video once its transcript seems
stable. As a result students are able to use ScalaCourses.com to learn
about the current shipping Scala technology.

Any breaking news that arises in the next couple of weeks regarding view
bounds will likely be incorporated into that lecture's video. At a
minimum, we'll circle back to this topic once 2.12 reaches RC status.

[Adriaan Moors]

Thanks for checking, Mike! There are no immediate plans to change their status. These tools will take some time to mature and be adopted.

[martin odersky]

View bounds are indeed on their way out, pending a tool that will
rewrite them automatically.

Cheers

- Martin

--
Martin Odersky
EPFL