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

(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.

On Tue, Jan 24, 2012 at 9:08 AM, Aleksandar Prokopec <aleksandar.prokopec@epfl.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".

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.prokopec@epfl.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.

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".

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

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.

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.

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.
>

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

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.)

>
> 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?

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?