List.flatten

Ok, I found the flatten method, and it's in the same boat as unzip:
both are unusable ATM because of implicit resolution errors. This is
currently failing:

scala> val xs = List((1, "one"), (2, "two"))
xs: List[(Int, java.lang.String)] = List((1,one), (2,two))

scala> xs.unzip
:6: error: value unzip is not a member of List[(Int,
java.lang.String)]
xs.unzip

Now method unzip is added post factum to traversables that are
instantiated at a pair type, using implicits of course. However, even
when the method is called explicitly, builders are not found at the
right types:

cala> pairTraversableWrapper[List[(Int, String)], Int, String](xs).unzip
:12: error: no implicit argument matching parameter type
scala.collection.generic.BuilderFactory[String,That2,List[(Int,
String)]] was found.
pairTraversableWrapper[List[(Int, String)], Int, String]
(xs).unzip

(note that I had to pass type parameters explicitly).

I can't really say if this is a bug in the compiler, or the collection
libraries miss something, but this should definitely be fixed before
2.8-preview.

iulian

On Jun 1, 2009, at 2:04 PM, Iulian Dragos wrote:

> It seems this method has been deprecated in object List, and removed
> in class List. The deprecation message says one should use the missing
> method on class List:
>
> /** Concatenate all the elements of a given list of lists.
> *
> * @param xss the list of lists that are to be concatenated
> * @return the concatenation of all the lists
> */
> @deprecated("use `xss.flatten' instead")
> def flatten[A](xss: List[List[A]]): List[A] = {
>
> Is there a problem if I undeprecate it? Grepping the compiler showed
> that it is still used in a couple of places.
>
> iulian
>
> --
> Iulian Dragos
> --
> http://lamp.epfl.ch/~dragos
>
>
>

--
Iulian Dragos
--
http://lamp.epfl.ch/~dragos

2009/6/1 Iulian Dragos :
> Ok, I found the flatten method, and it's in the same boat as unzip: both are
> unusable ATM because of implicit resolution errors. This is currently
> failing:
>
> scala> val xs = List((1, "one"), (2, "two"))
> xs: List[(Int, java.lang.String)] = List((1,one), (2,two))
>
> scala> xs.unzip
> :6: error: value unzip is not a member of List[(Int,
> java.lang.String)]
>       xs.unzip
>
> Now method unzip is added post factum to traversables that are instantiated
> at a pair type, using implicits of course. However, even when the method is
> called explicitly, builders are not found at the right types:
>
> cala> pairTraversableWrapper[List[(Int, String)], Int, String](xs).unzip
> :12: error: no implicit argument matching parameter type
> scala.collection.generic.BuilderFactory[String,That2,List[(Int, String)]]
> was found.
>       pairTraversableWrapper[List[(Int, String)], Int, String](xs).unzip
>
> (note that I had to pass type parameters explicitly).
>
> I can't really say if this is a bug in the compiler, or the collection
> libraries miss something, but this should definitely be fixed before
> 2.8-preview.

I have to say, I'm getting *very* uncomfortable with how sensitive the
new collections library is to implicit resolution[1]. Implicit
resolution is a dark art - it's underspecced, what spec there is is
very hard to understand, and it's always been my impression that
basically whether any give behaviour is or isn't an implicit bug can
only be determined by Martin, in no small part because the same holds
true of the type inferencer. The fact that the implicit resolution
mechanism and type inferencer had to be modified to make the new
collections library work and yet still many things that need to work
for it to be viable still don't work gives me a very bad feeling about
this.

[1] I know I was the one who suggested using implicits in this way,
but the way they worked in my original scheme was vastly simpler and
less fragile. It also did a lot less, which is why we more or less
concluded it wasn't viable given the design goals of the current
collection library. The fact that the new collections scheme gets as
far as it does is interesting and cool, but it doesn't seem to be
reliable.

On Mon, June 1, 2009 7:01 pm, Iulian Dragos wrote:
> I can't really say if this is a bug in the compiler, or the collection
> libraries miss something, but this should definitely be fixed before
> 2.8-preview.
>

For the record, the latest is that 2.8-preview might not actually happen,
or at least not in time for JavaOne. I asked Martin about the preview the
other day, and he seemed to indicate that trunk is too much in flux at
this time. We'll see how things evolve in a few days, I suppose.
Toni

On Mon, Jun 1, 2009 at 7:12 PM, David MacIver wrote:
> 2009/6/1 Iulian Dragos :
>> Ok, I found the flatten method, and it's in the same boat as unzip: both are
>> unusable ATM because of implicit resolution errors. This is currently
>> failing:
>>
>> scala> val xs = List((1, "one"), (2, "two"))
>> xs: List[(Int, java.lang.String)] = List((1,one), (2,two))
>>
>> scala> xs.unzip
>> :6: error: value unzip is not a member of List[(Int,
>> java.lang.String)]
>>       xs.unzip
>>
>> Now method unzip is added post factum to traversables that are instantiated
>> at a pair type, using implicits of course. However, even when the method is
>> called explicitly, builders are not found at the right types:
>>
>> cala> pairTraversableWrapper[List[(Int, String)], Int, String](xs).unzip
>> :12: error: no implicit argument matching parameter type
>> scala.collection.generic.BuilderFactory[String,That2,List[(Int, String)]]
>> was found.
>>       pairTraversableWrapper[List[(Int, String)], Int, String](xs).unzip
>>
>> (note that I had to pass type parameters explicitly).
>>
>> I can't really say if this is a bug in the compiler, or the collection
>> libraries miss something, but this should definitely be fixed before
>> 2.8-preview.
>
> I have to say, I'm getting *very* uncomfortable with how sensitive the
> new collections library is to implicit resolution[1]. Implicit
> resolution is a dark art - it's underspecced, what spec there is is
> very hard to understand, and it's always been my impression that
> basically whether any give behaviour is or isn't an implicit bug can
> only be determined by Martin, in no small part because the same holds
> true of the type inferencer. The fact that the implicit resolution
> mechanism and type inferencer had to be modified to make the new
> collections library work and yet still many things that need to work
> for it to be viable still don't work gives me a very bad feeling about
> this.

The problem here is simply that I am incredibly overloaded. I could
sorely need some help with both finishing collections and also specing
and refining implicits. Implicits.scala is actually quite well
documented; there's no huge barrier to entry. But most urgent is
completing the collection library.

Given enough help and time, I am a bit more optimistic. The fact that
progress on implicits and collections is coupled right now would be a
problem if we had to apply hacks to implicits just to make collections
work. But I believe it's largely gone the other way. I think I managed
to make implicits more general and rational, so in the end both
implicits and collections become more useful.

Besides, I do not really know of a good alternative to the present
scheme. Nobody has proposed anything that was workable so far.

The plan so far is to have a look at implicits again to see why
inference fails for flatten and tuple ops. We should resolve this
question first and then decide what to do about it.

Cheers