drop projections (= view)

[Stepan Koltsov]

Hi,

I propose dropping (or deprecating) collection projections (= views).

Because

* There is magic inside projections
* Performance is rarely critical (where lazy operation could give
significant benefit)
* Converting collections to projections and vice versa reduces program
readability
* There is no Map and Set views (view API is incomplete)
* ... but if performance is critical, one can still perform operations
on iterators where all operations are lazy and straightforward

I tried to use projections, and found them practically useless to me.

What do you think?

BTW, I'd also remove

* Synchronized* (because syncronization on collection is probably a
bad style of coding)
* Observable (because observing on collection is a bad style too)
* Undoable (who uses that?)
* Scriptable (rarely needed, may be done in user code)
* Stack (ArrayBuffer and LinkedList provide same features as in Stack,
just with different method names)
* *Proxy

Scala collections has too many classes ("Too big, too small? Size does
matter after all") especially after refactoring in 2.8.

S.

[Daniel Sobral]

I propose your feelings on this matter result from a lack of experience with functional programming, a non-functional programming style and lack of experience with the kind of code that makes use of such features.

I'd much appreciate a better definition of "magic" here. As for the other arguments, I simply disagree with all of them. As you have not argued why they are true, there's no place to debate them.

 

Instead, I'll just question one point: what does it matter if there are "too many" classes.  Would you argue that there are "too many" classes on Java Swing or AWT, for instance? And what is it that makes the richness of classes on collections a problem?

 

On Wed, Oct 28, 2009 at 11:29 PM, Stepan Koltsov <yozh@...> wrote:

Hi,

I propose dropping (or deprecating) collection projections (= views).

Because

* There is magic inside projections
* Performance is rarely critical (where lazy operation could give
significant benefit)
* Converting collections to projections and vice versa reduces program
readability
* There is no Map and Set views (view API is incomplete)
* ... but if performance is critical, one can still perform operations
on iterators where all operations are lazy and straightforward

I tried to use projections, and found them practically useless to me.

What do you think?

BTW, I'd also remove

* Synchronized* (because syncronization on collection is probably a
bad style of coding)
* Observable (because observing on collection is a bad style too)
* Undoable (who uses that?)
* Scriptable (rarely needed, may be done in user code)
* Stack (ArrayBuffer and LinkedList provide same features as in Stack,
just with different method names)
* *Proxy

Scala collections has too many classes ("Too big, too small? Size does
matter after all") especially after refactoring in 2.8.

S.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Stepan Koltsov]

2009/10/29 Daniel Sobral <dcsobral@...>:
> I propose your feelings on this matter result from a lack of experience with
> functional programming, a non-functional programming style and lack of
> experience with the kind of code that makes use of such features.

Thank you for your interesting opinion.

> I'd much appreciate a better definition of "magic" here. As for the other
> arguments, I simply disagree with all of them. As you have not argued why
> they are true, there's no place to debate them.

I cannot provide a strict definition of magic, but I can give and example.

===
scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5, 6).view.filter(x
=> { println("!"); x > 0 })
===

It result of this expression strict or lazy?

I believe, it should be lazy. But it is strict in latest dist: 6 excl
marks printed after expression evaluation, not when element accessed.

Actually, I believe, it is bug, because

===
List(1, 2, 3, 4, 5, 6).view.filter(x => { println("!"); x > 0 })
===

Prints 6 excl marks too (in 2.8.0.r19336-b20091029023417).

And this bug is a side-effect of design and impementation complexity (magic) .

However, when this bug is fixed, look at the expression:

===
val s: scala.collection.immutable.IndexedSeq[Int] =
  scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
6).view.filter(x => { println("!"); x > 0 })
===

"s" variable should contain lazy indexed seq. However, access of "s"
element by index is O(N) operation, that violates IndexedSeq
specification, that requires O(1) access.


> Instead, I'll just question one point: what does it matter if there are "too
> many" classes.  Would you argue that there are "too many" classes on Java
> Swing or AWT, for instance?

AWT classes are unavoidable: you need many classes when you have to
describe many types of objects in the underlying system (buttons,
lists, tables, layouts, colors, fonts, windows, titles, styles and so
on).

> And what is it that makes the richness of
> classes on collections a problem?

It makes standard library harder to learn to new developers, that
makes Scala spreading slower.

S.

> On Wed, Oct 28, 2009 at 11:29 PM, Stepan Koltsov <yozh@...> wrote:
>>
>> Hi,
>>
>> I propose dropping (or deprecating) collection projections (= views).
>>
>> Because
>>
>> * There is magic inside projections
>> * Performance is rarely critical (where lazy operation could give
>> significant benefit)
>> * Converting collections to projections and vice versa reduces program
>> readability
>> * There is no Map and Set views (view API is incomplete)
>> * ... but if performance is critical, one can still perform operations
>> on iterators where all operations are lazy and straightforward
>>
>> I tried to use projections, and found them practically useless to me.
>>
>> What do you think?
>>
>> BTW, I'd also remove
>>
>> * Synchronized* (because syncronization on collection is probably a
>> bad style of coding)
>> * Observable (because observing on collection is a bad style too)
>> * Undoable (who uses that?)
>> * Scriptable (rarely needed, may be done in user code)
>> * Stack (ArrayBuffer and LinkedList provide same features as in Stack,
>> just with different method names)
>> * *Proxy
>>
>> Scala collections has too many classes ("Too big, too small? Size does
>> matter after all") especially after refactoring in 2.8.

[Ken Bloom-2]

On Thu, 29 Oct 2009 20:03:48 +0300, Stepan Koltsov wrote:

> 2009/10/29 Daniel Sobral <dcsobral@...>:
>> I propose your feelings on this matter result from a lack of experience
>> with functional programming, a non-functional programming style and
>> lack of experience with the kind of code that makes use of such
>> features.
>
> Thank you for your interesting opinion.
>
>> I'd much appreciate a better definition of "magic" here. As for the
>> other arguments, I simply disagree with all of them. As you have not
>> argued why they are true, there's no place to debate them.
>
> I cannot provide a strict definition of magic, but I can give and
> example.
>
> ===
> scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5, 6).view.filter(x =>
> { println("!"); x > 0 })
> ===
>
> It result of this expression strict or lazy?
>
> I believe, it should be lazy. But it is strict in latest dist: 6 excl
> marks printed after expression evaluation, not when element accessed.
>
> Actually, I believe, it is bug, because
>
> ===
> List(1, 2, 3, 4, 5, 6).view.filter(x => { println("!"); x > 0 }) ===
>
> Prints 6 excl marks too (in 2.8.0.r19336-b20091029023417).
>
> And this bug is a side-effect of design and impementation complexity
> (magic) .

Are you running this in the read-eval-print loop (the interactive Scala
interpreter)? The "print" phase of the REPL causes the filter to be
evaluated.

Maybe we can change things so that view classes don't print their
contents in the REPL (thereby fooling people into thinking they're strict
when they're really not.)

--Ken


--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

[Seth Tisue]

>>>>> "Stepan" == Stepan Koltsov <yozh@...> writes:

 Stepan> === scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
 Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===

 Stepan> It result of this expression strict or lazy?

 Stepan> I believe, it should be lazy. But it is strict in latest dist:

No, it's lazy.  You tried it in the REPL and the REPL forced the
sequence in order to print it.

 Stepan> However, when this bug is fixed, look at the expression:
 Stepan> === val s: scala.collection.immutable.IndexedSeq[Int] =
 Stepan> scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
 Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===
 Stepan> "s" variable should contain lazy indexed seq. However, access
 Stepan> of "s" element by index is O(N) operation, that violates
 Stepan> IndexedSeq specification, that requires O(1) access.

How do you know it's O(n)?

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

[Stepan Koltsov-5]

On Thu, Oct 29, 2009 at 20:32, Seth Tisue <seth@...> wrote:

>>>>>> "Stepan" == Stepan Koltsov <yozh@...> writes:
>  Stepan> === scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
>  Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===
>
>  Stepan> It result of this expression strict or lazy?
>
>  Stepan> I believe, it should be lazy. But it is strict in latest dist:
>
> No, it's lazy.  You tried it in the REPL and the REPL forced the
> sequence in order to print it.

Oops, really. Then the bug is in toString implementation, that should
not have side effects (like toString in Stream, that does not print
elements until they are cached).


>  Stepan> However, when this bug is fixed, look at the expression:
>  Stepan> === val s: scala.collection.immutable.IndexedSeq[Int] =
>  Stepan> scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
>  Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===
>  Stepan> "s" variable should contain lazy indexed seq. However, access
>  Stepan> of "s" element by index is O(N) operation, that violates
>  Stepan> IndexedSeq specification, that requires O(1) access.
>
> How do you know it's O(n)?

OK, seems like it is not. I'm wrong again.

AFAIU, result of filter operation is cached, right? So it is not view,
it is cached view. I tried to find this in the implementation, and I
failed to find in 3 minutes. I read "view" method scaladocs, and
haven't found, that result is cached.

That all is "too much magic".

S.

[Daniel Sobral]

On Thu, Oct 29, 2009 at 3:03 PM, Stepan Koltsov <yozh@...> wrote:

 

2009/10/29 Daniel Sobral <dcsobral@...>:

 

> I propose your feelings on this matter result from a lack of experience with

> functional programming, a non-functional programming style and lack of

> experience with the kind of code that makes use of such features.

 

 

Thank you for your interesting opinion.

 

 

You may think it was a joke or derogatory, but it was neither. Having classes for "everything" looked absurd to programmers not used to Object Oriented Programming, but that was just lack of familiarity.

 

> I'd much appreciate a better definition of "magic" here. As for the other

> arguments, I simply disagree with all of them. As you have not argued why

> they are true, there's no place to debate them.

 

 

I cannot provide a strict definition of magic, but I can give and example.

 

 

How can we argue whether they are "magic" or not without a common understanding of what it means to be magic?

 

===

scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5, 6).view.filter(x

=> { println("!"); x > 0 })

===

 

It result of this expression strict or lazy?

 

 

I don't have IndexedSeq in the installed 2.8 I have in this computer, but it should be lazy. One expects the purely functional methods of the collection to be lazy on a view.

 

I believe, it should be lazy. But it is strict in latest dist: 6 excl

marks printed after expression evaluation, not when element accessed.

 

Actually, I believe, it is bug, because

 

===

List(1, 2, 3, 4, 5, 6).view.filter(x => { println("!"); x > 0 })

===

 

Prints 6 excl marks too (in 2.8.0.r19336-b20091029023417).

 

 

Prints how? Like this below?

 

scala> List(1, 2, 3, 4, 5, 6).view.filter(x => { println("!"); x > 0 })

!

!

!

!

!

!

res1: scala.collection.generic.SequenceView[Int,List[Int]] = SequenceTemplateF(1, 2, 3, 4, 5, 6)

 

Note that res1 was *printed*, which forces evaluation. In fact, if you tried it in a program, this would not have happened. Even on the REPL, you could do this:

 

scala> object X { var x = List(1, 2, 3, 4, 5, 6).view.filter(x => { println("!"); x > 0 }) }

defined module X

scala> X.x take 2

!

!

!

res5: scala.collection.generic.SequenceView[Int,List[Int]] = SequenceTemplateFS(1, 2)

 

So, lazily evaluated.

 

And this bug is a side-effect of design and impementation complexity (magic) .

 

It is not bug. This behaviour you don't understand is a direct-effect of lack of familiarity and experience with lazyness. Lazyness is a difficult concept, but, sometimes, there aren't easy work-arounds.

 

 

However, when this bug is fixed, look at the expression:

 

===

val s: scala.collection.immutable.IndexedSeq[Int] =

 scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,

6).view.filter(x => { println("!"); x > 0 })

===

 

"s" variable should contain lazy indexed seq. However, access of "s"

element by index is O(N) operation, that violates IndexedSeq

specification, that requires O(1) access.

 

 

1. IndexedSeq is barely 7 days in the trunk. That's what's called a "work in progress", so its present state isn't really a reference.

 

2. You are NOT working with a IndexedSeq, you are working with a VIEW on IndexedSeq, so IndexedSeq contract does not apply. Sorry, this is as basic as Int being different from Double.

 

 

> Instead, I'll just question one point: what does it matter if there are "too

> many" classes.  Would you argue that there are "too many" classes on Java

> Swing or AWT, for instance?

 

 

AWT classes are unavoidable: you need many classes when you have to

describe many types of objects in the underlying system (buttons,

lists, tables, layouts, colors, fonts, windows, titles, styles and so

on).

 

And, yet, the same applies to the collection richness. To me, AWT classes are useless. Of course, I don't write programs with GUI. Rich collections are fundamental, however.

 

 

> And what is it that makes the richness of

> classes on collections a problem?

 

 

It makes standard library harder to learn to new developers, that

makes Scala spreading slower.

 

The same can be said of AWT. It makes harder to learn for new developers. And the funny thing is... quite a few of them haven't learned it at all! And most of those who do know these classes have a partial knowledge of them, but certainly don't know everything about them.

 

This hasn't posed a problem to the market popularity of Java, though.

 

In fact, I'll make you a bet. I bet there isn't a single person on the whole planet who knows every official Java class, all its methods, and the precise semantics of each.

 

So why should Scala be saddled with a library so weak that beginners can actually learn all of it?

 

That is not only a misguided concern, but, in fact, highly detrimental.

 

 

S.

 

 

> On Wed, Oct 28, 2009 at 11:29 PM, Stepan Koltsov <yozh@...> wrote:

>>

>> Hi,

>>

>> I propose dropping (or deprecating) collection projections (= views).

>>

>> Because

>>

>> * There is magic inside projections

>> * Performance is rarely critical (where lazy operation could give

>> significant benefit)

>> * Converting collections to projections and vice versa reduces program

>> readability

>> * There is no Map and Set views (view API is incomplete)

>> * ... but if performance is critical, one can still perform operations

>> on iterators where all operations are lazy and straightforward

>>

>> I tried to use projections, and found them practically useless to me.

>>

>> What do you think?

>>

>> BTW, I'd also remove

>>

>> * Synchronized* (because syncronization on collection is probably a

>> bad style of coding)

>> * Observable (because observing on collection is a bad style too)

>> * Undoable (who uses that?)

>> * Scriptable (rarely needed, may be done in user code)

>> * Stack (ArrayBuffer and LinkedList provide same features as in Stack,

>> just with different method names)

>> * *Proxy

>>

>> Scala collections has too many classes ("Too big, too small? Size does

>> matter after all") especially after refactoring in 2.8.

 

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Daniel Sobral]

On Thu, Oct 29, 2009 at 4:02 PM, Stepan Koltsov <stepancheg@...> wrote:

On Thu, Oct 29, 2009 at 20:32, Seth Tisue <seth@...> wrote:
>>>>>> "Stepan" == Stepan Koltsov <yozh@...> writes:
>  Stepan> === scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
>  Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===
>
>  Stepan> It result of this expression strict or lazy?
>
>  Stepan> I believe, it should be lazy. But it is strict in latest dist:
>
> No, it's lazy.  You tried it in the REPL and the REPL forced the
> sequence in order to print it.

Oops, really. Then the bug is in toString implementation, that should
not have side effects (like toString in Stream, that does not print
elements until they are cached).

 

It is not a bug. First, there is no caching going on. Second, if I have something and I want its String representation, then I want its String representation. I want the code to evaluate that value and give it back to me as a String. It ceased to be a view, and became a String.

 

AFAIU, result of filter operation is cached, right? So it is not view,
it is cached view. I tried to find this in the implementation, and I
failed to find in 3 minutes. I read "view" method scaladocs, and
haven't found, that result is cached.

That's because it isn't.

 

That all is "too much magic".

"Too much magic" is Java's memory model. It can't be helped, though. This is way easier, but still complex, and it still can't be helped.

 

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Stepan Koltsov-2]

On Thu, Oct 29, 2009 at 20:25, Ken Bloom <kbloom@...> wrote:

> On Thu, 29 Oct 2009 20:03:48 +0300, Stepan Koltsov wrote:
>
>> 2009/10/29 Daniel Sobral <dcsobral@...>:
>>> I propose your feelings on this matter result from a lack of experience
>>> with functional programming, a non-functional programming style and
>>> lack of experience with the kind of code that makes use of such
>>> features.
>>
>> Thank you for your interesting opinion.
>>
>>> I'd much appreciate a better definition of "magic" here. As for the
>>> other arguments, I simply disagree with all of them. As you have not
>>> argued why they are true, there's no place to debate them.
>>
>> I cannot provide a strict definition of magic, but I can give and
>> example.
>>
>> ===
>> scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5, 6).view.filter(x =>
>> { println("!"); x > 0 })
>> ===
>>
>> It result of this expression strict or lazy?
>>
>> I believe, it should be lazy. But it is strict in latest dist: 6 excl
>> marks printed after expression evaluation, not when element accessed.
>>
>> Actually, I believe, it is bug, because
>>
>> ===
>> List(1, 2, 3, 4, 5, 6).view.filter(x => { println("!"); x > 0 }) ===
>>
>> Prints 6 excl marks too (in 2.8.0.r19336-b20091029023417).
>>
>> And this bug is a side-effect of design and impementation complexity
>> (magic) .
>
> Are you running this in the read-eval-print loop (the interactive Scala
> interpreter)? The "print" phase of the REPL causes the filter to be
> evaluated.
>
> Maybe we can change things so that view classes don't print their
> contents in the REPL (thereby fooling people into thinking they're strict
> when they're really not.)

toString should be changed.

S.

[Stepan Koltsov-5]

2009/10/29 Daniel Sobral <dcsobral@...>:

> On Thu, Oct 29, 2009 at 4:02 PM, Stepan Koltsov <stepancheg@...> wrote:
>>
>> On Thu, Oct 29, 2009 at 20:32, Seth Tisue <seth@...> wrote:
>> >>>>>> "Stepan" == Stepan Koltsov <yozh@...> writes:
>> >  Stepan> === scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
>> >  Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===
>> >
>> >  Stepan> It result of this expression strict or lazy?
>> >
>> >  Stepan> I believe, it should be lazy. But it is strict in latest dist:
>> >
>> > No, it's lazy.  You tried it in the REPL and the REPL forced the
>> > sequence in order to print it.
>>
>> Oops, really. Then the bug is in toString implementation, that should
>> not have side effects (like toString in Stream, that does not print
>> elements until they are cached).
>
>
> It is not a bug. First, there is no caching going on.

Could you please explain how it works then? I called toString on the
resulting "s" sequence several times, and got no more excl marks.
Filter was not called, so result was cached after first invocation,
no?

Screenshot of the session:

http://screencast.com/t/kNiBQxMT2


> Second, if I have
> something and I want its String representation, then I want its String
> representation. I want the code to evaluate that value and give it back to
> me as a String. It ceased to be a view, and became a String.

toString method is an object representation, not necessarily all
elements representation, because toString must not change object
state. If you need exactly all elements printed, you can call
mkString.

BTW, do you think Stream.toString should print all elements or those
already evaluated?


S.

[Stepan Koltsov-5]

On Thu, Oct 29, 2009 at 20:32, Seth Tisue <seth@...> wrote:

>>>>>> "Stepan" == Stepan Koltsov <yozh@...> writes:
>
>  Stepan> === scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
>  Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===
>
>  Stepan> It result of this expression strict or lazy?
>
>  Stepan> I believe, it should be lazy. But it is strict in latest dist:
>
> No, it's lazy.  You tried it in the REPL and the REPL forced the
> sequence in order to print it.

Hm. Now I again think, that there is a bug:

===
scala> scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
6).view.filter(x => { println("!"); x > 0 }).take(1)
!
!
!
!
!
!
res4: scala.collection.IndexedSeqView[Int,scala.collection.immutable.IndexedSeq[Int]]
= IndexedSeqViewFS()
===

I called take(1), but it printed 6 excl marks.

S.

[Linas-2]

On Thu, 2009-10-29 at 12:25 -0500, Ken Bloom wrote:
> On Thu, 29 Oct 2009 20:03:48 +0300, Stepan Koltsov wrote:
...
>
> Maybe we can change things so that view classes don't print their
> contents in the REPL (thereby fooling people into thinking they're strict
> when they're really not.)

Now that would really be "magic". Please, don't :)

Linas.

[Daniel Sobral]

IndexedSeq went into trunk 7 days ago. It is not ready. It does not, as yet, work as expected, because it is a work in progress in a non-released version of Scala.

 

IndexedSeq could explode nuclear devices as a side effect and it wouldn't matter, because it is -not- -ready-. Once the work in progress is finished, then we can talk about what it does or doesn't.

 

So, if you try "view" on List, which is pretty stable now, you'll see it isn't cached.

 

Actually, "non-strict" says nothing about caching, so you may not rely on such behavior unless explicitly stated. That, of course, rules out side-effects, but you are not supposed to mix side-effects and non-strictness anyway. If you want side effects, you must avoid views.

 

On Thu, Oct 29, 2009 at 4:39 PM, Stepan Koltsov <stepancheg@...> wrote:

On Thu, Oct 29, 2009 at 20:32, Seth Tisue <seth@...> wrote:

>>>>>> "Stepan" == Stepan Koltsov <yozh@...> writes:
>
>  Stepan> === scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
>  Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===
>
>  Stepan> It result of this expression strict or lazy?
>
>  Stepan> I believe, it should be lazy. But it is strict in latest dist:
>
> No, it's lazy.  You tried it in the REPL and the REPL forced the
> sequence in order to print it.

Hm. Now I again think, that there is a bug:

===
scala> scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
6).view.filter(x => { println("!"); x > 0 }).take(1)
!
!
!
!
!
!
res4: scala.collection.IndexedSeqView[Int,scala.collection.immutable.IndexedSeq[Int]]
= IndexedSeqViewFS()
===

I called take(1), but it printed 6 excl marks.

S.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Stepan Koltsov-5]

2009/10/30 Daniel Sobral <dcsobral@...>:
> IndexedSeq went into trunk 7 days ago. It is not ready. It does not, as yet,
> work as expected, because it is a work in progress in a non-released version
> of Scala.

When it is released, it is too late to complain.

> So, if you try "view" on List, which is pretty stable now, you'll see it
> isn't cached.

Pretty stable, huh. Try this:

===
List(1, 2, 3, 4, 5, 6).view.reverse
===

I get stack overflow. Too much magic cause these bugs :)

S.

[Stepan Koltsov-5]

On Fri, Oct 30, 2009 at 04:37, Stepan Koltsov <stepancheg@...> wrote:

> 2009/10/30 Daniel Sobral <dcsobral@...>:
>> IndexedSeq went into trunk 7 days ago. It is not ready. It does not, as yet,
>> work as expected, because it is a work in progress in a non-released version
>> of Scala.
>
> When it is released, it is too late to complain.
>
>> So, if you try "view" on List, which is pretty stable now, you'll see it
>> isn't cached.
>
> Pretty stable, huh. Try this:
>
> ===
> List(1, 2, 3, 4, 5, 6).view.reverse
> ===
>
> I get stack overflow. Too much magic cause these bugs :)

... in 2.8.0.r19336-b20091029023417

S.

[Andrew Gaydenko]

On Friday 30 October 2009 04:39:14 Stepan Koltsov wrote:
...
> > ===
> > List(1, 2, 3, 4, 5, 6).view.reverse
> > ===
> >
> > I get stack overflow. Too much magic cause these bugs :)
>
> ... in 2.8.0.r19336-b20091029023417


As well as r19350.

[Daniel Sobral]

Funny bug. I wonder if there's a ticket open for it. As for "released", I agree. Note that there will be release candidates and beta versions before then.

On Thu, Oct 29, 2009 at 11:37 PM, Stepan Koltsov <stepancheg@...> wrote:

2009/10/30 Daniel Sobral <dcsobral@...>:

> IndexedSeq went into trunk 7 days ago. It is not ready. It does not, as yet,
> work as expected, because it is a work in progress in a non-released version
> of Scala.

When it is released, it is too late to complain.

> So, if you try "view" on List, which is pretty stable now, you'll see it
> isn't cached.

Pretty stable, huh. Try this:

===
List(1, 2, 3, 4, 5, 6).view.reverse
===

I get stack overflow. Too much magic cause these bugs :)

S.

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Ken Bloom-2]

On Thu, 29 Oct 2009 21:37:01 +0300, Stepan Koltsov wrote:

> 2009/10/29 Daniel Sobral <dcsobral@...>:
>> On Thu, Oct 29, 2009 at 4:02 PM, Stepan Koltsov <stepancheg@...>
>> wrote:
>>>
>>> On Thu, Oct 29, 2009 at 20:32, Seth Tisue <seth@...> wrote:
>>> >>>>>> "Stepan" == Stepan Koltsov <yozh@...> writes:
>>> >  Stepan> === scala.collection.immutable.IndexedSeq(1, 2, 3, 4, 5,
>>> >  Stepan> 6).view.filter(x => { println("!"); x > 0 }) ===
>>> >
>>> >  Stepan> It result of this expression strict or lazy?
>>> >
>>> >  Stepan> I believe, it should be lazy. But it is strict in latest
>>> >  dist:
>>> >
>>> > No, it's lazy.  You tried it in the REPL and the REPL forced the
>>> > sequence in order to print it.
>>>
>>> Oops, really. Then the bug is in toString implementation, that should
>>> not have side effects (like toString in Stream, that does not print
>>> elements until they are cached).
>>
>>
>> It is not a bug. First, there is no caching going on.
>
> Could you please explain how it works then? I called toString on the
> resulting "s" sequence several times, and got no more excl marks. Filter
> was not called, so result was cached after first invocation, no?
>
> Screenshot of the session:
>
> http://screencast.com/t/kNiBQxMT2
>
>
>> Second, if I have
>> something and I want its String representation, then I want its String
>> representation. I want the code to evaluate that value and give it back
>> to me as a String. It ceased to be a view, and became a String.
>
> toString method is an object representation, not necessarily all
> elements representation, because toString must not change object state.
> If you need exactly all elements printed, you can call mkString.
>
> BTW, do you think Stream.toString should print all elements or those
> already evaluated?

None -- it should just say it's a lazy collection.

--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

[Randall Schulz]

On Thursday October 29 2009, Stepan Koltsov wrote:
> ... Too much magic cause these bugs :)

Flawed implementations cause bugs.


> S.


RRS

[Tiark Rompf]

On 29.10.2009, at 22:22, Daniel Sobral wrote:

> IndexedSeq went into trunk 7 days ago. It is not ready. It does not,  
> as yet, work as expected, because it is a work in progress in a non-
> released version of Scala.

Can you be a bit more precise about how IndexedSeq/Vector does not  
work as expected?

IndexedSeqView was previously called VectorView and has been around  
for months. Besides its name, nothing changed 7 days ago. You can  
trigger the same behavior with Strings instead of new-style Vectors:

        "abcdef".view.filter { x => println("!"); x != 'a' }.take(2)

- Tiark