any explanation for scala implementation of iterable concatenation?

On Sun, Feb 22, 2009 at 03:45:08PM -0800, Vlad Patryshev wrote:
> And what's the reason? Why not lazy? Why return Collection? Why not
> something like the following?
>
> def ++ [B >: A](that: Iterable[B]): Iterable[B] = new Iterable[B] {
> override elements = this.elements ++ that.elements
> }

I have no explanation, but if you look at the new collections library in trunk you will see

override def ++[B >: A](that: Iterable[B]): IterableView[UC, B] = newView(elements ++ that.elements)

which ought to be more your speed.

On Mon, Feb 23, 2009 at 1:11 AM, Paul Phillips wrote:
> On Sun, Feb 22, 2009 at 03:45:08PM -0800, Vlad Patryshev wrote:
>> And what's the reason? Why not lazy? Why return Collection? Why not
>> something like the following?
>>
>> def ++ [B >: A](that: Iterable[B]): Iterable[B] = new Iterable[B] {
>>   override elements = this.elements ++ that.elements
>> }
>
> I have no explanation, but if you look at the new collections library in trunk you will see
>
>  override def ++[B >: A](that: Iterable[B]): IterableView[UC, B] = newView(elements ++ that.elements)
>
> which ought to be more your speed.
>
> --
> Paul Phillips      | Beware of bugs in the above code; I have only
> Protagonist        | proved it correct, not tried it.
> Empiricist         |     -- Knuth
> pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------
>
It's very important to be clear and consistent where operations are
lazy and where they are not.
In 2.8 the policy will be that all operations on strict collections
are strict. In 2.7, there were a couple of operations (such as slice)
where this was not the case.
If you want lazy operations you have to create a view (this is called
projection in 2.7, but we'll change the name). I.e.

xs.view ++ ys
xs.view.map(f)

would both be computed lazily.

Cheers

This is all very neat! And "view" is much, much better than
"projection". I always thought about "dropping columns" wherever I saw
them (in a relational algebra fashion)...

Cheers!

O/H martin odersky έγραψε:
> It's very important to be clear and consistent where operations are
> lazy and where they are not.
> In 2.8 the policy will be that all operations on strict collections
> are strict. In 2.7, there were a couple of operations (such as slice)
> where this was not the case.
> If you want lazy operations you have to create a view (this is called
> projection in 2.7, but we'll change the name). I.e.
>
> xs.view ++ ys
> xs.view.map(f)
>
> would both be computed lazily.
>
> Cheers
>

On Fri, Feb 27, 2009 at 10:51 PM, Dimitris Andreou
wrote:
> This is all very neat! And "view" is much, much better than "projection". I
> always thought about "dropping columns" wherever I saw them (in a relational
> algebra fashion)...

I have to be honest and say that I'm not all that enthused by "view"
as the name here given the clash with the usage in documenting view
bounds, implicits and their connection with Wadlers views.

I love the design tho' ... so maybe another name? Seeing as what we're
after is something which is dual to "force" how about "delay" or
"defer"?

Cheers,

Miles

Miles Sabin wrote:
> On Fri, Feb 27, 2009 at 10:51 PM, Dimitris Andreou
> wrote:
>> This is all very neat! And "view" is much, much better than "projection". I
>> always thought about "dropping columns" wherever I saw them (in a relational
>> algebra fashion)...
>
> I have to be honest and say that I'm not all that enthused by "view"
> as the name here given the clash with the usage in documenting view
> bounds, implicits and their connection with Wadlers views.
>
> I love the design tho' ... so maybe another name? Seeing as what we're
> after is something which is dual to "force" how about "delay" or
> "defer"?

Why not simply "lazy" (or some term containing lazy)?

/Jesper Nordenberg

On Sat, Feb 28, 2009 at 12:01 AM, Miles Sabin wrote:
> On Fri, Feb 27, 2009 at 10:51 PM, Dimitris Andreou
> wrote:
>> This is all very neat! And "view" is much, much better than "projection". I
>> always thought about "dropping columns" wherever I saw them (in a relational
>> algebra fashion)...
>
> I have to be honest and say that I'm not all that enthused by "view"
> as the name here given the clash with the usage in documenting view
> bounds, implicits and their connection with Wadlers views.
>
> I love the design tho' ... so maybe another name? Seeing as what we're
> after is something which is dual to "force" how about "delay" or
> "defer"?
>
I initially also thought of delay, but then was reminded by Sean that
projections/views can also apply to mutable structures such as arrays.
`delay' seems less approriate for a prefix of an update operation like

array.view.reverse(0) = x

Cheers

On Fri, Feb 27, 2009 at 11:06 PM, Jesper Nordenberg wrote:
>> I love the design tho' ... so maybe another name? Seeing as what we're
>> after is something which is dual to "force" how about "delay" or
>> "defer"?
>
> Why not simply "lazy" (or some term containing lazy)?

That would be great but for the fact that "lazy" is a keyword ...

Cheers,

Miles

On Fri, Feb 27, 2009 at 11:28 PM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Feb 27, 2009 at 11:06 PM, Jesper Nordenberg <megagurka@yahoo.com> wrote:
>> I love the design tho' ... so maybe another name? Seeing as what we're
>> after is something which is dual to "force" how about "delay" or
>> "defer"?
>
> Why not simply "lazy" (or some term containing lazy)?

That would be great but for the fact that "lazy" is a keyword ...

And also the fact that projections/views/whatever are call by name, not lazy.

On Fri, Feb 27, 2009 at 11:05 PM, martin odersky wrote:
> I initially also thought of delay, but then was reminded by Sean that
> projections/views can also apply to mutable structures such as arrays.
> `delay' seems less approriate for a prefix of an update operation like
>
> array.view.reverse(0) = x

I might be missing something, but surely delay is exactly the concept
we want in just this case,

array.delay.reverse(0) = x

so long as we read delay as grouped with reverse ...

Cheers,

Miles

David MacIver wrote:
> On Fri, Feb 27, 2009 at 11:28 PM, Miles Sabin > wrote:
>
> On Fri, Feb 27, 2009 at 11:06 PM, Jesper Nordenberg
> > wrote:
> >> I love the design tho' ... so maybe another name? Seeing as what
> we're
> >> after is something which is dual to "force" how about "delay" or
> >> "defer"?
> >
> > Why not simply "lazy" (or some term containing lazy)?
>
> That would be great but for the fact that "lazy" is a keyword ...
>
>
> And also the fact that projections/views/whatever are call by name, not
> lazy.

You might call them "lazy with a really bad memory".

/Jesper Nordenberg

On Fri, Feb 27, 2009 at 11:40 PM, Jesper Nordenberg <megagurka@yahoo.com> wrote:

David MacIver wrote:

On Fri, Feb 27, 2009 at 11:28 PM, Miles Sabin <miles@milessabin.com <mailto:miles@milessabin.com>> wrote:

   On Fri, Feb 27, 2009 at 11:06 PM, Jesper Nordenberg
   <megagurka@yahoo.com
   <mailto:megagurka@yahoo.com>> wrote:
    >> I love the design tho' ... so maybe another name? Seeing as what
   we're
    >> after is something which is dual to "force" how about "delay" or
    >> "defer"?
    >
    > Why not simply "lazy" (or some term containing lazy)?

   That would be great but for the fact that "lazy" is a keyword ...


And also the fact that projections/views/whatever are call by name, not lazy.

You might call them "lazy with a really bad memory".

My mistake. I thought lazy = call by need, but actually it seems to be the same as non-strict.

asLazy ?

Viktor,
Rogue Software Architect

28 feb 2009 kl. 00.05 martin odersky skrev:

> On Sat, Feb 28, 2009 at 12:01 AM, Miles Sabin
> wrote:
>> On Fri, Feb 27, 2009 at 10:51 PM, Dimitris Andreou
>> wrote:
>>> This is all very neat! And "view" is much, much better than
>>> "projection". I
>>> always thought about "dropping columns" wherever I saw them (in a
>>> relational
>>> algebra fashion)...
>>
>> I have to be honest and say that I'm not all that enthused by "view"
>> as the name here given the clash with the usage in documenting view
>> bounds, implicits and their connection with Wadlers views.
>>
>> I love the design tho' ... so maybe another name? Seeing as what
>> we're
>> after is something which is dual to "force" how about "delay" or
>> "defer"?
>>
> I initially also thought of delay, but then was reminded by Sean that
> projections/views can also apply to mutable structures such as arrays.
> `delay' seems less approriate for a prefix of an update operation like
>
> array.view.reverse(0) = x
>
> Cheers
>

On Sat, Feb 28, 2009 at 9:17 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

asLazy ?

beLazy, surely. ;-)

But I'm not sure that this conveys the right behaviour for mutable collections. I actually still like view the best of the options presented.

I have thought about it in the past but did not put forward the idea for any particular reason.
I believe that "view" means semantically something like a constraint on the original collection. For example an ordered collection view can be a sub-collection with specific start and stop indexes. In this example the "view" notion translates almost literally: it is as if we have a window over the original collection. Also, generally speaking, a filtered collection is some kind of a view of the original collection. 
So, "asLazy" seems natural for the semantics currently discussed. I would also like to propose the dual "asEager". Without going into lengthy discussions (non-strict vs. lazy etc), other forms may be:
asLazy, asNonStrict, nonStrict, lazee (!)asEager, asStrict, strict

BRChristos
On Sat, Feb 28, 2009 at 11:17 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

asLazy ?

Viktor,
Rogue Software Architect

28 feb 2009 kl. 00.05 martin odersky <martin.odersky@epfl.ch> skrev:

On Sat, Feb 28, 2009 at 12:01 AM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Feb 27, 2009 at 10:51 PM, Dimitris Andreou
<jim.andreou@gmail.com> wrote:

This is all very neat! And "view" is much, much better than "projection". I
always thought about "dropping columns" wherever I saw them (in a relational
algebra fashion)...

I have to be honest and say that I'm not all that enthused by "view"
as the name here given the clash with the usage in documenting view
bounds, implicits and their connection with Wadlers views.

I love the design tho' ... so maybe another name? Seeing as what we're
after is something which is dual to "force" how about "delay" or
"defer"?

I initially also thought of delay, but then was reminded by Sean that
projections/views can also apply to mutable structures such as arrays.
`delay' seems less approriate for a prefix of an update operation like

array.view.reverse(0) = x

Cheers

David MacIver wrote:
> On Sat, Feb 28, 2009 at 9:17 AM, Viktor Klang > wrote:
>
> asLazy ?
>
>
> beLazy, surely. ;-)
>
> But I'm not sure that this conveys the right behaviour for mutable
> collections. I actually still like view the best of the options presented.

Note that, to avoid unnecessary copying, it's quite valuable to be able
to "slice" a collection lazily but perform map/flatMap/filter operations
strictly on the slice. This would be a semi-lazy view. :)

/Jesper Nordenberg

LazyView?

Sent from my iPhone
On Feb 28, 2009, at 7:04 AM, David MacIver <david.maciver@gmail.com> wrote:

On Sat, Feb 28, 2009 at 9:17 AM, Viktor Klang < (viktor [dot] klang [at] gmail [dot] com> wrote:

asLazy ?

beLazy, surely. ;-)

But I'm not sure that this conveys the right behaviour for mutable collections. I actually still like view the best of the options presented.

Oh dear ... I really didn't mean to start a bikeshedding exercise :-(

Cheers,

Miles

C.toLazyView.splice(a,b).filter(_ == c).toList

Seems to me like we already have toXYZ methods, we not fit that
paradigm? Couldn't existing toXYZ methods be used for "eager-ifying"
a lazy view of a collection?

On Feb 28, 2009, at 7:55 AM, Jesper Nordenberg
wrote:

> David MacIver wrote:
>> On Sat, Feb 28, 2009 at 9:17 AM, Viktor Klang
>> > wrote:
>> asLazy ?
>> beLazy, surely. ;-)
>> But I'm not sure that this conveys the right behaviour for mutable
>> collections. I actually still like view the best of the options
>> presented.
>
> Note that, to avoid unnecessary copying, it's quite valuable to be
> able to "slice" a collection lazily but perform map/flatMap/filter
> operations strictly on the slice. This would be a semi-lazy view. :)
>
> /Jesper Nordenberg
>

I realise it doesn't fit well with the monadic nature of things[1], but I really like how listOfStrings.Select(s => s.Length) returns an IEnumerable<int> in C# (the elements are evaluated as needed).  Then if you want something strict out you get to write .ToList(), .ToArray() etc. afterwards.
So the default is to be lazier than Scala.  I think it's a simpler approach and generally encourages laziness (by making strict require an extra method call).
Technically the developer can choose the implementation and types of Select anyway - System.Linq provides the one I described, but it would be straightforward to provide another Select implementation that behaves more like Scala's - it would be nice to have that kind of flexibility in Scala too, but as map, flatMap, filter etc. are defined directly on the types rather than by imported implicit conversions, we don't have that flexibility.
End braindump.
2009/2/28 Miles Sabin <miles@milessabin.com>

Oh dear ... I really didn't mean to start a bikeshedding exercise :-(

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

I propose "asBikeShed."  Or should that be "toBikeShed?"

On Sat, Feb 28, 2009 at 5:31 AM, Miles Sabin <miles@milessabin.com> wrote:

Oh dear ... I really didn't mean to start a bikeshedding exercise :-(

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

On Sat, Feb 28, 2009 at 6:04 PM, James Iry <jamesiry@gmail.com> wrote:

I propose "asBikeShed."  Or should that be "toBikeShed?"

Not to forget the elusive isBikeShed and asBikeShedFactoryBuilder
 

- Show quoted text -

On Sat, Feb 28, 2009 at 5:31 AM, Miles Sabin <miles@milessabin.com> wrote:

Oh dear ... I really didn't mean to start a bikeshedding exercise :-(

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

--
Viktor Klang
Senior Systems Analyst

I think "as" and "to" really imply different semantics.  I would expect an "as" method to return a facade to the original object that conforms to the specified interface, while I would expect to make a new independent object.
If the objects are immutable than the distinction isn't important.  But if the objects are mutable the difference between a facade and an independent object are critical.

On Sat, Feb 28, 2009 at 12:04 PM, James Iry <jamesiry@gmail.com> wrote:

I propose "asBikeShed."  Or should that be "toBikeShed?"

On Sat, Feb 28, 2009 at 5:31 AM, Miles Sabin <miles@milessabin.com> wrote:

Oh dear ... I really didn't mean to start a bikeshedding exercise :-(

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

--
http://erikengbrecht.blogspot.com/

On Sat, Feb 28, 2009 at 4:47 PM, Ricky Clarkson
wrote:
> I realise it doesn't fit well with the monadic nature of things[1], but I
> really like how listOfStrings.Select(s => s.Length) returns an
> IEnumerable in C# (the elements are evaluated as needed).  Then if you
> want something strict out you get to write .ToList(), .ToArray() etc.
> afterwards.
> So the default is to be lazier than Scala.  I think it's a simpler approach
> and generally encourages laziness (by making strict require an extra method
> call).
> Technically the developer can choose the implementation and types of Select
> anyway - System.Linq provides the one I described, but it would be
> straightforward to provide another Select implementation that behaves more
> like Scala's - it would be nice to have that kind of flexibility in Scala
> too, but as map, flatMap, filter etc. are defined directly on the types
> rather than by imported implicit conversions, we don't have that
> flexibility.
> End braindump.

For what it's worth, this is how the alternative collections library I
sketched out a while ago worked. Everything returned Traversables and
you were encouraged not to override this fact: Instead you provided
builder objects. So everything was fully call by name and you forced
strictness at the end.

I thought it worked quite well, but it never really went anywhere.

There are lazy collections, such as Views or Streams.
And then there are strict ones such as List or ArrayBuffer.
I think we all agree on uniformity as a principle . Operations
returning a another collection of the same type such as map, or
filter, or ++, should all be either lazy or strict. But for lists for
instance, it feels awkward to have map return a stream or list view,
not a list. (and it's certainly too late to change that now).
So we chose to make all operations on strict collections strict,
except for view, which gives you a lazy collection. As long as
one is consistent, this is quite easy to deal with, I think.
The problem with the current collection library is that it is not 100%
consistent.

Cheers

Do bikeshed discussions belong to a special type class?

class BikeShed shed where

  paint :: color -> shed color                      -- make up some shed color


  (<*>) :: shed (c1 -> c2) -> shed c1 -> shed c2    -- apply color over somebody else's


    __~o
  -\ <,
 (*)/ (*) :: shed c1 -> (c1 -> shed c2) -> shed c2  -- Luc Duponcheel's effecful bikeshed bind

On Sat, Feb 28, 2009 at 9:04 AM, James Iry <jamesiry@gmail.com> wrote:

I propose "asBikeShed."  Or should that be "toBikeShed?"

On Sat, Feb 28, 2009 at 5:31 AM, Miles Sabin <miles@milessabin.com> wrote:

Oh dear ... I really didn't mean to start a bikeshedding exercise :-(

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

Do you really need a builder to make factories for sheds that store bikes?  Why not just a meta-factory that produces things that somewhat resemble bicycle sheds.  That way it's more reusable.

On Sat, Feb 28, 2009 at 12:14 PM, Viktor Klang <viktor.klang@gmail.com> wrote:

On Sat, Feb 28, 2009 at 6:04 PM, James Iry <jamesiry@gmail.com> wrote:

I propose "asBikeShed."  Or should that be "toBikeShed?"

Not to forget the elusive isBikeShed and asBikeShedFactoryBuilder
 

- Show quoted text -

On Sat, Feb 28, 2009 at 5:31 AM, Miles Sabin <miles@milessabin.com> wrote:

Oh dear ... I really didn't mean to start a bikeshedding exercise :-(

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

--
Viktor Klang
Senior Systems Analyst