Comments on: Scala Collections for the Easily Bored Part 1: A Tale of Two Flavors http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1 (permanently in beta) Sun, 29 Aug 2010 20:01:44 -0700 http://wordpress.org/?v=2.9.2 hourly 1 By: Design Pattern http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-4940 Design Pattern Fri, 19 Feb 2010 19:45:11 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-4940 @Ali In the first example, you do NOT change the immutable Set, but you do assign a (reference to) new Set to variable jetSet. In the second example you modify the original set. Try without the import: scala> val movieSet = Set("Hitch", "Poltegeist") movieSet: scala.collection.immutable.Set[java.lang.String] = Set(Hitch, Poltegeist) scala> movieSet += "Scary Movie" :6: error: reassignment to val movieSet += "Scary Movie" ^ @Ali

In the first example, you do NOT change the immutable Set,
but you do assign a (reference to) new Set to variable jetSet.

In the second example you modify the original set.

Try without the import:
scala> val movieSet = Set(“Hitch”, “Poltegeist”)
movieSet: scala.collection.immutable.Set[java.lang.String] = Set(Hitch, Poltegeist)

scala> movieSet += “Scary Movie”
:6: error: reassignment to val
movieSet += “Scary Movie”
^

]]> By: Ali http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-4930 Ali Tue, 02 Feb 2010 12:43:49 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-4930 Daniel, I'm a bit confused about 2 examples in Programming in Scala: var jetSet = Set ("Boeing", "Airbus") //immutable set jetSet += "Lear" // but we can still change it? and this as well: import scala.collection.mutable.Set val movieSet = Set("Hitch","Poltegeist") movieSet += "Shrek" What's the difference between these? Daniel,

I’m a bit confused about 2 examples in Programming in Scala:

var jetSet = Set (“Boeing”, “Airbus”) //immutable set
jetSet += “Lear” // but we can still change it?

and this as well:

import scala.collection.mutable.Set
val movieSet = Set(“Hitch”,”Poltegeist”)
movieSet += “Shrek”

What’s the difference between these?

]]> By: Daniel Spiewak http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-4919 Daniel Spiewak Tue, 29 Dec 2009 06:24:41 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-4919 Actually, it's not so much of an irregularity. Array is a specific implementation of Seq, whereas Set is a generic abstraction. When you say Set(), the result is an instance of some implementation, but you don't know which one. Because Array is just an interface to direct, random-access memory, you can't have multiple implementations. In practice, arrays aren't used all that much in Scala. Most of the time, I find myself using toArray from some other Seq built in a functional manner, and then only when I have to interact with a legacy Java API which requires raw arrays. Actually, it’s not so much of an irregularity. Array is a specific implementation of Seq, whereas Set is a generic abstraction. When you say Set(), the result is an instance of some implementation, but you don’t know which one. Because Array is just an interface to direct, random-access memory, you can’t have multiple implementations.

In practice, arrays aren’t used all that much in Scala. Most of the time, I find myself using toArray from some other Seq built in a functional manner, and then only when I have to interact with a legacy Java API which requires raw arrays.

]]> By: jeffpk http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-4918 jeffpk Tue, 29 Dec 2009 03:52:20 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-4918 So... whiy is it that, according to Orderksy et al in Programming in Scala... To get an instance of an array you write: new Array But to get an instance of a Set you type: Set() This irregularity is truly ugly. So… whiy is it that, according to Orderksy et al in Programming in Scala…

To get an instance of an array you write: new Array
But to get an instance of a Set you type: Set()

This irregularity is truly ugly.

]]> By: Chris de Vreeze http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-3974 Chris de Vreeze Sat, 23 Aug 2008 17:33:25 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-3974 Ok, I see what you are getting at. Btw, thanks for your blogs on Scala for Java developers. They are really helpful. Ok, I see what you are getting at. Btw, thanks for your blogs on Scala for Java developers. They are really helpful.

]]> By: Daniel Spiewak http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-3973 Daniel Spiewak Sat, 23 Aug 2008 16:38:06 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-3973 I chose toSet() as a simple example to show how to use immutable collections in a semi-practical setting. Obviously you would use something a bit more compact (like your idiom) in the real world. :-) As to the problems... Take a gander at the signature for List#flatMap. By all rights, its function parameter should be constrained to return a value of type List[B]. However, this is not possible conventionally due to the fact that method parameters vary *contravariantly* and return types vary *covariantly*. This means that the only sound overriding of the flatMap method would have to define the function parameter to either return Iterable[B] (as in the superclass) or any supertype of Iterable[B]. Very annoying restriction. Higher kinds allow us to get around this, but Scala's collections API was built before the introduction of higher-kind inference. I'm not entirely sure why the collections API hasn't been rewritten to take advantage of this powerful addition to the type system, but unfortunately that's the way it is. I chose toSet() as a simple example to show how to use immutable collections in a semi-practical setting. Obviously you would use something a bit more compact (like your idiom) in the real world. :-)

As to the problems… Take a gander at the signature for List#flatMap. By all rights, its function parameter should be constrained to return a value of type List[B]. However, this is not possible conventionally due to the fact that method parameters vary *contravariantly* and return types vary *covariantly*. This means that the only sound overriding of the flatMap method would have to define the function parameter to either return Iterable[B] (as in the superclass) or any supertype of Iterable[B]. Very annoying restriction.

Higher kinds allow us to get around this, but Scala’s collections API was built before the introduction of higher-kind inference. I’m not entirely sure why the collections API hasn’t been rewritten to take advantage of this powerful addition to the type system, but unfortunately that’s the way it is.

]]> By: Chris de Vreeze http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-3972 Chris de Vreeze Sat, 23 Aug 2008 12:40:01 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-3972 Frankly, I still fail to see the problems with Scala collections. In your example, you could have directly written: val nameSet = Set() ++ names Such idioms to convert between different types of collections are not so bad, right? You are undoubtedly aware of this, so I'm surprised you did not mention it. Frankly, I still fail to see the problems with Scala collections. In your example, you could have directly written:
val nameSet = Set() ++ names
Such idioms to convert between different types of collections are not so bad, right? You are undoubtedly aware of this, so I’m surprised you did not mention it.

]]> By: Daniel Spiewak http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-3845 Daniel Spiewak Mon, 21 Jul 2008 18:16:41 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-3845 Yeah, no arguments here. :-) To be honest l, I really don't understand why Scala's collections are so constrained. The type system can certainly handle a better design (as your work with Scalaz shows). Hopefully, the LAMP team will take some inspiration from you and fix the defects in a future release. With that said, it's really not all that bad for practical purposes. Obviously, it's annoying that methods like map work on Iterable and not the specific subtype. In normal usage, however, it isn't really a big deal. If nothing else, even crippled Scala collections are far more powerful than their Java counterparts. :-) Yeah, no arguments here. :-) To be honest l, I really don’t understand why Scala’s collections are so constrained. The type system can certainly handle a better design (as your work with Scalaz shows). Hopefully, the LAMP team will take some inspiration from you and fix the defects in a future release.

With that said, it’s really not all that bad for practical purposes. Obviously, it’s annoying that methods like map work on Iterable and not the specific subtype. In normal usage, however, it isn’t really a big deal. If nothing else, even crippled Scala collections are far more powerful than their Java counterparts. :-)

]]> By: Tony Morris http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1/comment-page-1#comment-3843 Tony Morris Mon, 21 Jul 2008 08:58:19 +0000 http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-1#comment-3843 "Fortunately, Scala’s mutable collections have an almost identical interface to its immutable collections." This is one of the reasons that abstracting over a type constructor can bring great rewards without the repetition. Frankly, I'm very unimpressed with the core Scala library; oh except for scala.Either of course; that was written by a really handsome bloke :) I have some libraries that abstract over type constructors in Scalaz 2, but I have rewritten it all for Scalaz 3 (hoping to release this week) with some much better examples. This defers the choice of whether you wish to use mutable or immutable data types in your own code. See Monad, Functor, Applicative, MonadPlus, MonadEmpty, Foldable, etc. “Fortunately, Scala’s mutable collections have an almost identical interface to its immutable collections.”

This is one of the reasons that abstracting over a type constructor can bring great rewards without the repetition. Frankly, I’m very unimpressed with the core Scala library; oh except for scala.Either of course; that was written by a really handsome bloke :)

I have some libraries that abstract over type constructors in Scalaz 2, but I have rewritten it all for Scalaz 3 (hoping to release this week) with some much better examples. This defers the choice of whether you wish to use mutable or immutable data types in your own code.

See Monad, Functor, Applicative, MonadPlus, MonadEmpty, Foldable, etc.

]]>