Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

view gaps #4332

Closed
scabug opened this issue Mar 11, 2011 · 19 comments
Closed

view gaps #4332

scabug opened this issue Mar 11, 2011 · 19 comments
Assignees
Labels
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Mar 11, 2011

These are particularly bad because they are runtime failures with no obvious way to know what will fail. Example.

scala> List(1,2,3).view.dropRight(1)
java.lang.UnsupportedOperationException: SeqView(...).newBuilder
	at scala.collection.TraversableViewLike$$class.newBuilder(TraversableViewLike.scala:53)
	at scala.collection.SeqLike$$$$anon$$2.newBuilder(SeqLike.scala:978)
	at scala.collection.IterableLike$$class.dropRight(IterableLike.scala:176)
	at scala.collection.SeqLike$$$$anon$$2.dropRight(SeqLike.scala:978)
	at .<init>(<console>:8)
	at .<clinit>(<console>)
	at .<init>(<console>:11)
	at .<clinit>(<console>)
	at $$export(<console>)

It would make a lot more sense to me if views implemented an abstract interface (and thus the compiler would tell us what methods aren't covered) than having them override all kinds of inherited implementations, with runtime failure for methods which are missed or otherwise elude the concrete barriers.

(Get it, concrete barriers? That is gold.)

@scabug
Copy link
Author

@scabug scabug commented Mar 11, 2011

@scabug
Copy link
Author

@scabug scabug commented Mar 15, 2011

@adriaanm said:
This is indeed a tricky problem. Unfortunately, there's no-one with enough bandwidth to tackle this right now -- could you nurture this ticket for a while and bounce it back later?

@scabug
Copy link
Author

@scabug scabug commented Mar 15, 2011

@paulp said:
I will nurture it like the beautiful boilerplate baby it is.

@scabug
Copy link
Author

@scabug scabug commented Aug 18, 2011

Kieron Wilkinson (kieron) said:
I have just run into the below problem in 2.9.0.1.

scala> (1 to Int.MaxValue).view.filter(_ % 2 == 0).takeWhile(_ < 10)
java.lang.UnsupportedOperationException: SeqViewF(...).newBuilder
at scala.collection.TraversableViewLike$class.newBuilder(TraversableViewLike.scala:69)
at scala.collection.SeqViewLike$$anon$5.newBuilder(SeqViewLike.scala:79)
at scala.collection.IterableLike$class.takeWhile(IterableLike.scala:139)
at scala.collection.SeqViewLike$$anon$5.takeWhile(SeqViewLike.scala:79)
at scala.collection.SeqViewLike$$anon$5.takeWhile(SeqViewLike.scala:79)
at .(:8)
at .()
at .(:11)
at .()
at $export()
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:592)
at scala.tools.nsc.interpreter.IMain$Request$$anonfun$10.apply(IMain.scala:828)
at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV$sp(Line.scala:43)
at scala.tools.nsc.io.package$$anon$2.run(package.scala:31)
at java.lang.Thread.run(Thread.java:662)

Are improving the views not too much of a priority at the moment?

I have been playing with views to show at some tutorial sessions at my company to teach functional programming (e.g. creating a set of natural numbers to use in computations). I'd rather use views because I don't care to cache intermediate values, like I understand Stream to do - I'm not really selling functional programming by creating large intermediate collections around :)

I guess I should just avoid them, because I don't want it to blow up during a demo :) but I thought I would check in to see if there is a plan for these, or maybe I could look into it myself if any patches I might submit are likely to get accepted some time soon?

Thanks!

@scabug
Copy link
Author

@scabug scabug commented Oct 7, 2011

Nikolay Artamonov (nartamonov) said:
For now, scala collection views are not usable at all, see errors below. It is very bad thing, since there are NO WARNINGS about broken feature in API docs. I thought Scala API is more or less stable, disregarding small bugs. I believe it is wrong to leave broken features in Scala releases.

scala> util.Properties.versionString
res9: java.lang.String = version 2.9.1.final

scala> Seq(1,2,3,4).view(1,3).slice(0,1)
java.lang.UnsupportedOperationException: SeqViewS(...).newBuilder
at scala.collection.TraversableViewLike$class.newBuilder(TraversableView
Like.scala:69)
at scala.collection.SeqViewLike$$anon$6.newBuilder(SeqViewLike.scala:80)

    at scala.collection.IterableLike$class.slice(IterableLike.scala:95)
    at scala.collection.SeqViewLike$$anon$6.slice(SeqViewLike.scala:80)
    at scala.collection.SeqViewLike$$anon$6.slice(SeqViewLike.scala:80)

... skipped ...

@scabug
Copy link
Author

@scabug scabug commented Jan 4, 2013

@SethTisue said:
Another kind of gap is operations that don't fail at runtime, but don't give view-like behavior, either. For example, scanLeft on a SeqView is eager in both 2.9.2 and 2.10.0:

scala> List.range(1, 5).view.scanLeft(0){case (a, b) => println(b); a + b}
1
2
3
4
res4: scala.collection.SeqView[Int,Seq[_]] = SeqViewC(...)

@scabug
Copy link
Author

@scabug scabug commented Mar 15, 2013

@adriaanm said:
Un-assigning to foster work stealing, as announced in https://groups.google.com/forum/?fromgroups=#!topic/scala-internals/o8WG4plpNkw

@scabug
Copy link
Author

@scabug scabug commented May 7, 2013

@Ichoran said:
The methods that fail with UnsupportedOperationException (as far as I know) are

combinations
distinct
dropRight
inits
permutations
tails
takeRight

@scabug
Copy link
Author

@scabug scabug commented May 7, 2013

@paulp said:
Views are hopelessly broken as I have noted too many times to count over the last FIVE YEARS, and the fact that we continue to ship them in this hopelessly broken form ought to make people seriously question our fitness for the task of being responsible for a "standard" library. It doesn't seem to have this effect, so I guess we will keep shipping hopelessly broken code.

@scabug
Copy link
Author

@scabug scabug commented May 8, 2013

@vigdorchik said (edited on May 8, 2013 12:19:34 PM UTC):
dropRight and takeRight are obviously fixable.
distinct needs an implementation.
Others can be forced, though not so sure about combinations where only a prefix is needed.

@scabug
Copy link
Author

@scabug scabug commented May 8, 2013

@paulp said:
It will remain hopelessly broken as long as the present design is perpetuated. Vastly superior alternative designs are possible.

@scabug
Copy link
Author

@scabug scabug commented May 8, 2013

@vigdorchik said:
Do you have anything in mind already? Something already sketched?

@scabug
Copy link
Author

@scabug scabug commented May 8, 2013

@paulp said:
There are a bunch of threads. https://groups.google.com/forum/#!topic/scala-debate/M8s8FmASL8Y is one.

Here's some code I found, dated 2 years 1 month ago. I stress that this isn't necessarily what I would expect to go with; there are a number of plausible approaches.

https://github.com/paulp/views

@scabug
Copy link
Author

@scabug scabug commented Jun 26, 2013

@retronym said:
Another example from #7610

scala> a.view.map { _+1}.filter{_%2==0}.distinct
java.lang.UnsupportedOperationException: SeqViewMF(...).newBuilder
at scala.collection.TraversableViewLike$class.newBuilder(TraversableViewLik

@scabug
Copy link
Author

@scabug scabug commented Jun 26, 2013

Edmondo Porcu (edmondo1984) said:
I've hit the problem with the SeqViewLike. all the methods of SeqLike not overriden in the trait are forwarded back to the SeqLike trait, and try to use the standard builder. From what I could see in the code I think this could be case for other collection as well.

I wonder if it would not be safer for the community to deprecate or remove views and favour iterator style in one of the next releases. This is a small non breaking change that will immediately force user to run away from views.

@scabug
Copy link
Author

@scabug scabug commented Jul 10, 2013

@adriaanm said:
Unassigning and rescheduling to M6 as previous deadline was missed.

@scabug
Copy link
Author

@scabug scabug commented Nov 25, 2013

@retronym said:
Discussion of a solution to identify current and future view gaps: scala/scala#3191 (comment)

@scabug
Copy link
Author

@scabug scabug commented Nov 25, 2013

@SethTisue
Copy link
Member

@SethTisue SethTisue commented Jun 5, 2018

views are completely reimplemented in the 2.13 collections on a sounder basis and should work now (as of 2.13.0-M4)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants