This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Fwd: Re: [scala-devel] Traversable.force(), mutability and laziness

10 replies
prokopec
Joined: 2010-02-19,
User offline. Last seen 34 weeks 5 days ago.
(1) Moved to scala internals.

(2) Perhaps an alternative to having an overload would be to have only the `force` from the views and move it all the way to the top of the hierarchy.
Note that the current semantics of *View.force is slightly different, as it constructs a new collection using the provided builder factory, rather than forcing the current collection.


-------- Original Message --------

Date: Tue, 24 Jan 2012 11:59:07 -0500 From: Josh Suereth joshua [dot] suereth [at] gmail [dot] com (<joshua [dot] suereth [at] gmail [dot] com>)





(1) Can we discuss on scala-internals?
(2) Do we need the overload?  
+1 in general for the idea.

On Tue, Jan 24, 2012 at 11:42 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" rel="nofollow">aleksandar [dot] prokopec [at] epfl [dot] ch> wrote:
Due to bugs like this one:

https://issues.scala-lang.org/browse/SI-5377?focusedCommentId=55931#comment-55931

involving streams and lazy collections in general which typically have to do with the lazy collection being constructed lazily from some mutable object or collection, I suggest we introduce a method on `Traversable` which wouldn't do anything for most collections, but would actually force lazy collections like streams.

I was thinking `force()` would be a good name:

   def force(): this.type

but then it would be overloaded for views, where `force` has a different signature:

   def force[B >: A, That](implicit bf: CanBuildFrom[Coll, B, That]): That

This would allow calling `force` on the `result` below and avoid bugs related to laziness and mutability in a generic way, rather than through pattern matching on the type of `result`.

     val elms: Array[A] = getArrayOfElements()
     val result = (self.newBuilder ++= elms.toList).result // the result is not completely constructed here if self is a Stream
     changeArray(elms)

Thoughts on this?

Cheers,
Alex

--
Aleksandar Prokopec,
Doctoral Assistant
LAMP, IC, EPFL
http://people.epfl.ch/aleksandar.prokopec


extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and


On Tue, Jan 24, 2012 at 9:08 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch> wrote:
(2) Perhaps an alternative to having an overload would be to have only the `force` from the views and move it all the way to the top of the hierarchy.
Note that the current semantics of *View.force is slightly different, as it constructs a new collection using the provided builder factory, rather than forcing the current collection.

Which is too bad, because "force" should mean to force lazy evaluation.  When you "force" a view you aren't really forcing anything. You've set your rube goldberg machine up and you're running a marble through it, but when the marble gets there you can do it again, and the view is as it was.
"Force" connotes that a change has taken place in the thing being forced.  Otherwise you wouldn't have had to force it, it would have simply happened.
A more accurate name for operation on views would be "realize", as in "realize my vision!" Or perhaps "actualize".
Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and


On Wed, Jan 25, 2012 at 12:44 AM, Paul Phillips <paulp [at] improving [dot] org> wrote:


On Tue, Jan 24, 2012 at 9:08 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch> wrote:
(2) Perhaps an alternative to having an overload would be to have only the `force` from the views and move it all the way to the top of the hierarchy.
Note that the current semantics of *View.force is slightly different, as it constructs a new collection using the provided builder factory, rather than forcing the current collection.

Which is too bad, because "force" should mean to force lazy evaluation.  When you "force" a view you aren't really forcing anything. You've set your rube goldberg machine up and you're running a marble through it, but when the marble gets there you can do it again, and the view is as it was.
"Force" connotes that a change has taken place in the thing being forced.  Otherwise you wouldn't have had to force it, it would have simply happened.
A more accurate name for operation on views would be "realize", as in "realize my vision!" Or perhaps "actualize".

Seeing a patch of unpainted bikeshed, I jump in and propose "IReallyMeanIt()" 


--
Viktor Klang

Akka Tech LeadTypesafe - The software stack for applications that scale

Twitter: @viktorklang
prokopec
Joined: 2010-02-19,
User offline. Last seen 34 weeks 5 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and
On 1/25/12 12:44 AM, Paul Phillips wrote:
CAEaELhQOeiEYBPLud9_XnunuCNg3jpAxH-4O2rszpZvv-x01kw [at] mail [dot] gmail [dot] com" type="cite">
On Tue, Jan 24, 2012 at 9:08 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch" rel="nofollow">aleksandar [dot] prokopec [at] epfl [dot] ch> wrote:
(2) Perhaps an alternative to having an overload would be to have only the `force` from the views and move it all the way to the top of the hierarchy.
Note that the current semantics of *View.force is slightly different, as it constructs a new collection using the provided builder factory, rather than forcing the current collection.

Which is too bad, because "force" should mean to force lazy evaluation.  When you "force" a view you aren't really forcing anything. You've set your rube goldberg machine up and you're running a marble through it, but when the marble gets there you can do it again, and the view is as it was.

Nicely put.

CAEaELhQOeiEYBPLud9_XnunuCNg3jpAxH-4O2rszpZvv-x01kw [at] mail [dot] gmail [dot] com" type="cite"> "Force" connotes that a change has taken place in the thing being forced.  Otherwise you wouldn't have had to force it, it would have simply happened.
A more accurate name for operation on views would be "realize", as in "realize my vision!" Or perhaps "actualize".
Or `evaluate`?
I don't know if we can change the current name of force for views, but perhaps we should. The only issue is that we'd first have to deprecate the current `force` in views.



-- 
Aleksandar Prokopec,
Doctoral Assistant
LAMP, IC, EPFL
http://people.epfl.ch/aleksandar.prokopec
extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and

On Wed, Jan 25, 2012 at 1:15 AM, Aleksandar Prokopec
wrote:
> I don't know if we can change the current name of force for views, but
> perhaps we should. The only issue is that we'd first have to deprecate the
> current `force` in views.

The good news is that it has a different signature than what ought to
be the signature of the `force` under discussion, so a deprecated
view-force can coexist with a new force-force.

def force[B >: A, That](implicit bf: CanBuildFrom[Coll, B, That])

The "real" force doesn't need a builder.

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and

On Wed, Jan 25, 2012 at 1:15 AM, Aleksandar Prokopec
wrote:
> Or `evaluate`?

That has the right denotation in this context, but has the material
weakness that it's among the most overused words in computer science.
I may be an outlier when it comes to naming things, but I would much
prefer names which are distinct, memorable, and meaningful, even if
they are likely to be initially surprising. It's not like I spend a
lot of time running around trying to guess the names of methods out of
thin air.

A good example of this is that there was a whole little uproar when I
named a method which takes a File and returns a String containing its
contents as `slurp`. This was a naming tragedy of major proportions
for some people. To me, it's still the best name.

prokopec
Joined: 2010-02-19,
User offline. Last seen 34 weeks 5 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and

I agree with this - evaluate is already used in many contexts.

On 1/25/12 10:27 PM, Paul Phillips wrote:
> On Wed, Jan 25, 2012 at 1:15 AM, Aleksandar Prokopec
> wrote:
>> Or `evaluate`?
> That has the right denotation in this context, but has the material
> weakness that it's among the most overused words in computer science.
> I may be an outlier when it comes to naming things, but I would much
> prefer names which are distinct, memorable, and meaningful, even if
> they are likely to be initially surprising. It's not like I spend a
> lot of time running around trying to guess the names of methods out of
> thin air.
>
> A good example of this is that there was a whole little uproar when I
> named a method which takes a File and returns a String containing its
> contents as `slurp`. This was a naming tragedy of major proportions
> for some people. To me, it's still the best name.
>

prokopec
Joined: 2010-02-19,
User offline. Last seen 34 weeks 5 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and

On 1/25/12 10:20 PM, Paul Phillips wrote:
> The good news is that it has a different signature than what ought to
> be the signature of the `force` under discussion, so a deprecated
> view-force can coexist with a new force-force.
>
> def force[B>: A, That](implicit bf: CanBuildFrom[Coll, B, That])
>
> The "real" force doesn't need a builder.
>

True, but in the case of views, it would create a subtle difference
between calling:

xs.view.force // calls the actualize-force

and

xs.view.force() // calls the real-force

Not that the real-force should do anything for views, _unless_ it's a
view of a lazy collection.

Alex

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and

On Thu, Jan 26, 2012 at 2:03 AM, Aleksandar Prokopec
wrote:
> True, but in the case of views, it would create a subtle difference between
> calling:

Agree this is less than ideal, and it would be a deal killer as an
element of the design, but we'd only have to fade it for 2.10, and
after that the implicit-taking force could go. The statistics on view
usage I gathered for the "a view to a kill" thread indicate to me that
the intersection of "people using views", "people calling force on
views", and "people doing something with forced views which is likely
to be subverted by overloading the method", and "people who never read
deprecation messages" is going to be pretty small between now and
2.11.

(Speaking of same, I know I still owe you email re: the
implementation, a lapse for which I feel terrible guilt. I seem to
have made modest progress on reducing the number of balls I have in
the air, though I'm not sure whether the primary responsible party is
me or gravity.)

prokopec
Joined: 2010-02-19,
User offline. Last seen 34 weeks 5 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and

>
> the intersection of "people using views", "people calling force on
> views", and "people doing something with forced views which is likely
> to be subverted by overloading the method", and "people who never read
> deprecation messages" is going to be pretty small between now and
> 2.11.

I would agree with this line of thought.
Just pointing out that there might be a small hairball in there,
although we wouldn't have to live with it for long.

> (Speaking of same, I know I still owe you email re: the
> implementation, a lapse for which I feel terrible guilt. I seem to
> have made modest progress on reducing the number of balls I have in
> the air, though I'm not sure whether the primary responsible party is
> me or gravity.)
> .
>

I feel the same guilt :)
Is what you've done so far available to see?

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Fwd: Re: [scala-devel] Traversable.force(), mutability and
I use force a lot to generate a "strict" collection from a "view".  A rarely ever use views against Stream, as I try to avoid Stream like the plague in general.  It's rare that I need something besides TraversableView for laziness.
- Josh

On Thu, Jan 26, 2012 at 8:59 AM, Aleksandar Prokopec <aleksandar [dot] prokopec [at] epfl [dot] ch> wrote:


the intersection of "people using views", "people calling force on
views", and "people doing something with forced views which is likely
to be subverted by overloading the method", and "people who never read
deprecation messages" is going to be pretty small between now and
2.11.

I would agree with this line of thought.
Just pointing out that there might be a small hairball in there, although we wouldn't have to live with it for long.


(Speaking of same, I know I still owe you email re: the
implementation, a lapse for which I feel terrible guilt.  I seem to
have made modest progress on reducing the number of balls I have in
the air, though I'm not sure whether the primary responsible party is
me or gravity.)
.


I feel the same guilt :)
Is what you've done so far available to see?


Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland