Keeping a collection views type

If you want lazy, why not go direct to iterator? Don't pass go, don't collect $200

Using views like this feels risky.

On Feb 17, 2012 7:48 PM, "Ka Ter" <ter.ka966@googlemail.com> wrote:

Hi,

how can I denote a method (or function) that takes a TraversalView and
does return one without changing to a pure Traversal? On a pure
traversal I cannot call force() so I need again a TraversalView.
In the method body I do some collection based operations that should
keep the origin traversal type.

This seems to be an important piece when building a collection based dsl
that has to differ between strict and lazy collection classes.

Any ideas?

In the following code I get the error:
Cannot construct a collection of type That with elements of type
Test.Element based on a collection of type
scala.collection.TraversableView[Test.Element,Traversable[Test.Element]].
not enough arguments for method test: (implicit cbf:
scala.collection.generic.CanBuildFrom[scala.collection.TraversableView[Test.Element,Traversable[Test.Element]],Test.Element,That])That.
Unspecified value parameter cbf.

import scala.collection.TraversableView
import scala.collection.generic.CanBuildFrom
object Test
{
   class Element

   def main(args: Array[String]): Unit =
   {
       def test[E <: Element, That <: TraversableView[E,
Traversable[E]]](source: TraversableView[E, Traversable[E]])(
               implicit cbf: CanBuildFrom[TraversableView[E,
Traversable[E]], E, That]): That =
       {
           source.filter(a => true) ++ source.map(a => a)(cbf)
       }

       val result = test(Set(new Element).view).force
   }
}

--
Best Regards

Ka Ter

ok. But I thought iterators were strict, too? Why are there views when iterators do the same thing?

Best Regards

Ka Ter

Am 17.02.2012 20:54, schrieb Kevin Wright:

CABHxxC03xj8F2_mxLBDY075Za4Zx1f30iuFO2qL6nZRP7mTfgw [at] mail [dot] gmail [dot] com" type="cite">

If you want lazy, why not go direct to iterator? Don't pass go, don't collect $200

Using views like this feels risky.

On Feb 17, 2012 7:48 PM, "Ka Ter" <ter [dot] ka966 [at] googlemail [dot] com" rel="nofollow">ter.ka966@googlemail.com> wrote:

Hi,

how can I denote a method (or function) that takes a TraversalView and
does return one without changing to a pure Traversal? On a pure
traversal I cannot call force() so I need again a TraversalView.
In the method body I do some collection based operations that should
keep the origin traversal type.

This seems to be an important piece when building a collection based dsl
that has to differ between strict and lazy collection classes.

Any ideas?

In the following code I get the error:
Cannot construct a collection of type That with elements of type
Test.Element based on a collection of type
scala.collection.TraversableView[Test.Element,Traversable[Test.Element]].
not enough arguments for method test: (implicit cbf:
scala.collection.generic.CanBuildFrom[scala.collection.TraversableView[Test.Element,Traversable[Test.Element]],Test.Element,That])That.
Unspecified value parameter cbf.

import scala.collection.TraversableView
import scala.collection.generic.CanBuildFrom
object Test
{
   class Element

   def main(args: Array[String]): Unit =
   {
       def test[E <: Element, That <: TraversableView[E,
Traversable[E]]](source: TraversableView[E, Traversable[E]])(
               implicit cbf: CanBuildFrom[TraversableView[E,
Traversable[E]], E, That]): That =
       {
           source.filter(a => true) ++ source.map(a => a)(cbf)
       }

       val result = test(Set(new Element).view).force
   }
}

--
Best Regards

Ka Ter

I assume (and am willing to be corrected here) that views exist because they

a. can retain type information about the expected resulting collection when forced

b. can potentially offer better performance in some circumstances through knowledge of the underlying structure. e.g. a view can know when it's safe to buffer results, an iterator had no such guarantee.

As always, it doesn't mean that such optimisations have been done, just that they're theoretically possible.

On Feb 17, 2012 9:17 PM, "Ka Ter" <ter.ka966@googlemail.com> wrote:

ok. But I thought iterators were strict, too? Why are there views when iterators do the same thing?

Best Regards

Ka Ter

Am 17.02.2012 20:54, schrieb Kevin Wright:

If you want lazy, why not go direct to iterator? Don't pass go, don't collect $200

Using views like this feels risky.

On Feb 17, 2012 7:48 PM, "Ka Ter" <ter.ka966@googlemail.com> wrote:

Hi,

how can I denote a method (or function) that takes a TraversalView and
does return one without changing to a pure Traversal? On a pure
traversal I cannot call force() so I need again a TraversalView.
In the method body I do some collection based operations that should
keep the origin traversal type.

This seems to be an important piece when building a collection based dsl
that has to differ between strict and lazy collection classes.

Any ideas?

In the following code I get the error:
Cannot construct a collection of type That with elements of type
Test.Element based on a collection of type
scala.collection.TraversableView[Test.Element,Traversable[Test.Element]].
not enough arguments for method test: (implicit cbf:
scala.collection.generic.CanBuildFrom[scala.collection.TraversableView[Test.Element,Traversable[Test.Element]],Test.Element,That])That.
Unspecified value parameter cbf.

import scala.collection.TraversableView
import scala.collection.generic.CanBuildFrom
object Test
{
   class Element

   def main(args: Array[String]): Unit =
   {
       def test[E <: Element, That <: TraversableView[E,
Traversable[E]]](source: TraversableView[E, Traversable[E]])(
               implicit cbf: CanBuildFrom[TraversableView[E,
Traversable[E]], E, That]): That =
       {
           source.filter(a => true) ++ source.map(a => a)(cbf)
       }

       val result = test(Set(new Element).view).force
   }
}

--
Best Regards

Ka Ter

Ok, I tried two variants, but none of them compile:

1)
        class Element
       
        def test[C <: Traversable[Element], B, That](traversable: C)(
                implicit cbf: CanBuildFrom[C, B, That]): That =
traversable.map(a => a)(cbf)
       
        test(Set[Element]()).contains(new Element)

2)     
        class Element2
       
        def test2[E <: Element, C[E] <: Traversable[E], B,
That](traversable: C[E])(
                implicit cbf: CanBuildFrom[C[E], B, That]): That =
traversable.map(a => a)(cbf)
               
        test2(Set[Element]()).contains(new Element2)

The problem is in both cases the following:

1) type mismatch;  found   :
scala.collection.generic.CanBuildFrom[C,B,That]  required: 
scala.collection.generic.CanBuildFrom[Traversable[Element],Element,That]

2) type mismatch;  found   :
scala.collection.generic.CanBuildFrom[C[E],B,That]  required:
scala.collection.generic.CanBuildFrom[Traversable[E],E,That]   
NewTestQuery.scala


How can I get the method test to emit a Set thus I can use the contains
Method?

Best Regards

Ka Ter

Am 17.02.2012 22:27, schrieb Kevin Wright:

CABHxxC1-TzYzfkXw70GpvDuc4QmvYQ9B1i8z12y4qGwegXM89g [at] mail [dot] gmail [dot] com" type="cite">

I assume (and am willing to be corrected here) that views exist because they

a. can retain type information about the expected resulting collection when forced

b. can potentially offer better performance in some circumstances through knowledge of the underlying structure. e.g. a view can know when it's safe to buffer results, an iterator had no such guarantee.

As always, it doesn't mean that such optimisations have been done, just that they're theoretically possible.

On Feb 17, 2012 9:17 PM, "Ka Ter" <ter [dot] ka966 [at] googlemail [dot] com" rel="nofollow">ter.ka966@googlemail.com> wrote:

ok. But I thought iterators were strict, too? Why are there views when iterators do the same thing?

Best Regards

Ka Ter

Am 17.02.2012 20:54, schrieb Kevin Wright:

If you want lazy, why not go direct to iterator? Don't pass go, don't collect $200

Using views like this feels risky.

On Feb 17, 2012 7:48 PM, "Ka Ter" <ter [dot] ka966 [at] googlemail [dot] com" target="_blank" rel="nofollow">ter.ka966@googlemail.com> wrote:

Hi,

how can I denote a method (or function) that takes a TraversalView and
does return one without changing to a pure Traversal? On a pure
traversal I cannot call force() so I need again a TraversalView.
In the method body I do some collection based operations that should
keep the origin traversal type.

This seems to be an important piece when building a collection based dsl
that has to differ between strict and lazy collection classes.

Any ideas?

In the following code I get the error:
Cannot construct a collection of type That with elements of type
Test.Element based on a collection of type
scala.collection.TraversableView[Test.Element,Traversable[Test.Element]].
not enough arguments for method test: (implicit cbf:
scala.collection.generic.CanBuildFrom[scala.collection.TraversableView[Test.Element,Traversable[Test.Element]],Test.Element,That])That.
Unspecified value parameter cbf.

import scala.collection.TraversableView
import scala.collection.generic.CanBuildFrom
object Test
{
   class Element

   def main(args: Array[String]): Unit =
   {
       def test[E <: Element, That <: TraversableView[E,
Traversable[E]]](source: TraversableView[E, Traversable[E]])(
               implicit cbf: CanBuildFrom[TraversableView[E,
Traversable[E]], E, That]): That =
       {
           source.filter(a => true) ++ source.map(a => a)(cbf)
       }

       val result = test(Set(new Element).view).force
   }
}

--
Best Regards

Ka Ter

On Fri, Feb 17, 2012 at 22:17, Ka Ter wrote:
> ok. But I thought iterators were strict, too? Why are there views when
> iterators do the same thing?
>
> Best Regards
>
> Ka Ter

Hi!

You might find this talk relevant:
http://days2010.scala-lang.org/node/138/152 Leaky Monads - An
Experiment with Automatic Resource Management
by Josh Suereth. He talks quite a bit about how to achieve something
very similar.

cheers,
Pas