Does Scala have any well developed libraries in the spirit of Haskell's pipes, or at least iteratee?
I found Play's iteratee library first, but I couldn't make it work, and it seems tightly coupled with Play's concurrency primitive Promise, which could be inappropriate in many cases.
Scalaz has some iteratee support (like IterV), but it seems there are only core classes with no additional support functions, predefined iteratees/enumerators etc. Also I couldn't find any documentation, even scaladoc is very sparse, so it's quite difficult to use properly.
And I couldn't find anything similar to pipes.
Building up on comments from Travis, currently there are:
Scalaz 7 iteratee package (iterv, you mentioned, is a compatibility layer with scalaz 6)
A port of Conduit library
Runar's scala-machines library (presentation, haskell version)
Related
Just for the sake of quick clarity for someone who wants to start working with Scala FP library, on a journey to become better at pure FP.
Would someone clarify the difference/relation between Cats and Cats-Effect, Cats-Effects IO? On top of that, where does Zio, and Monix stand with respect to it? Finally, what would be the relation to ScalaZ 7/8?
So far based on what I have read, a good combination of the library to work with based on the documentation available and what they do would be Cats, then Cats-Effect, and ZIO which could be used with Cats-effects? But I can't quite understand well why and would like to set myself a good path to learn to be better FP programmer while remaining productive, and not having to finish "FP Programming in Scala" before I start making choices.
Scalaz started as an attempt to port to Scala some well-established abstractions from Haskell (like typeclasses for Monad, Functor and much more). Problem with it was, that it doesn't have great documentation, so basically, you needed to use documentation of Haskell libraries in order to understand how to use certain Scalaz resources.
Nowadays, you there's Sam Halliday’s Functional Programming for Mortals which you can use as a learning source for Scalaz.
Cats was created later, as essentially reimplementation what Scalaz provided. Cats has a lot better documentation than Scalaz, there is also great book Scala with Cats.
Scalaz and Cats might have very similar purposes, so they're competing as general purpose FP library for Scala. There are also libraries that serve as compatibility-layer between both libraries.
Cats-Effect is a library, which provides "standard" IO monad for Scala (again idea borrowed from Haskell (?)). It depends on code from Cats core library.
You can read more here why there is a need for IO monad for Scala, when there's standard's library Future.
Monix is another library, which provides an IO monad for Scala, but this time it's called Task. It was meant to be a more high-level abstraction and provide easier interop with code using standard library Future. In reality, it shares a lot of code with Cats-Effect and creator of Monix Alexandru Nedelcu is also one of the main contributors of Cats-Effect.
Here you may find more information about the differences between cats.effect.IO and monix.eval.Task, as well as some of the history of both.
Lastly, there is ZIO which started as an attempt to reimplement IO monad for Scalaz, but ended up as a completely separate library (so it does not depend on Scalaz codebase).
The great thing about all libraries is, they're all implementing typeclasses (like Sync or Concurrent) from Cats-Effect, so using pattern called tagless final you're able to switch between implementation.
That hierarchy of typeclasses also serve as an interpolation library between, many (all (?)) of the IO implementations (as by the time it was created there already were fs2.Task, monix.Task & scalaz.IO). Also, apparently, in a future the IO part may be moved into another module, leaving only the interoperability typeclasses.
If you don't use tagless final you can still use modules that provide interop between certain IO monads, for example zio-interop-cats (between ZIO and Cats-Effect or catnap for Monix-Cats-Effect.
For your information, I recently extended this answer into a full-fledged blog post.
Is anyone aware of a standard API equivalent to Akka's ByteString: http://doc.akka.io/api/akka/2.3.5/index.html#akka.util.ByteString
This very convenient class has no dependency on any other Akka code, and it saddens me to have to import the whole Akka jar just to use it.
I found this fairly old discussion mentioning adding it to the standard API, but I don't know what happened to this project: https://groups.google.com/forum/#!msg/scalaz/ZFcjGpZswRc/0tCIdXvpGBAJ
Does anyone know of an equivalent piece of code in the standard API? Or in a very lightweight library?
You might want to check out scodec-bits. It provides two types, BitVector and ByteVector (API docs), supporting fast appends, take, drop, random access, etc. The library has zero dependencies. We split it out of scodec precisely because we thought it might of general use outside of scodec, where it's used heavily.
Clojure has this amazing library implementing Tony Hoare's Communicating Sequential Processes called core.async.
Haskell appears to have an equivalent called chp. (Not sure if it compiles under GHC 7.8).
My question is Is there an equivalent of Haskell's CHP for Scala?
You should have a look at this:
https://groups.google.com/forum/#!msg/scala-user/NljrQ4Mc-aI/3ISm68sqLNAJ
It provides a really interesting list of alternatives for doing CSP in Scala and doesn't recommend JCSP since it's development apparently stopped in 2011.
It also talks about a really interesting paper written by Andrew Bate at Oxford that describes a DSL in Scala for CSP but that whose implementation hasn't been open sourced.
It finally describes Quasar that seems the best alternative. If you're interested in Quasar, this post gives a good description of how Quasar works.
Given a Scala AST, is there a way to generate Scala source code?
I'm looking into ways to autogenerate Scala source by parsing/analyzing other Scala source. Any tips would be appreciated!
I have been successfully using Scala-Refactoring by Mirko Stocker for this task.
For synthetically constructing ASTs, it relies strongly on the existing Tree DSL of Scala's NSC.
Although the code is a bit messy, you can find an example usage in my project ScalaCollider-UGens.
I have also come across a very useful class by Johannes Rudolph.
See our DMS Software Reengineering Toolkit.
DMS provides a complete ecosystem for parsing/analyzing/optimizing/transforming source code in many languages. It achieves this by provide generic machinery for these tasks as its core capabilities, and specializing those according to explicitly supplied language definitions ("front ends"). DMS has front ends for many languages (C, C++, C#, Java, COBOL, ...) that have been used in anger, and a process for defining others very quickly.
We work on expanding the language set more or less continuously. DMS already has parts of a Scala front end implemented, and we know how to finish it based on the other 30+ front ends we have built, with special emphasis on knowledge of Java.
Many of the available resources for learning Scala assume some background in Java. This can prove challenging for someone who is trying to learn Scala with no Java background.
What are some Java-isms a new Scala developer should know about as they learn the language?
For example, it's useful to know what a CLASSPATH is, what the java command line options are, etc...
That's a really great question! I've never thought about people learning Java just so they have it easier to learn Scala...
Apart from all the basics like for loops and such, learning Java Generics can be really helpful. The Scala equivalent is much more potent (and much harder to understand) than Java Generics. You might want to try to figure out where the limits of Java Generics are, and then in which cases Scala's type constructors can be used to overcome those limitations. At the more basic level, it is important to know why Generics are necessary, and how Java is a strongly typed language.
Java allows you to have multiple constructors for one class. This knowledge will be of no use when you learn Scala, because Scala has another way that allows you to offer several methods to create instances of a class. So, you'd rather not have a deep look into this Java concept.
Here are some concepts that differ very strongly between Java and Scala. So, if you learn the Java concepts and then later on want to learn the equivalent in Scala, you should be aware that the Scala equivalent differs so greatly from the Java version that a typical Java developer will have some difficulty to adapt to the Scala way of thinking. Still, it usually helps to first get used to the Java way, because it is usually simpler and easier to learn. I personally prefer to think of Java as the introductory course, and Scala is the pro version.
Java mutable collection concept vs. Scala mutable/immutable differentiation
static methods (Java) vs. singleton objects (Scala)
for loops
Java return statement vs. Scala functional style ("every expression returns a value")
Java's use of null for "no value" vs. Scala's more explicit Option type
imports
Java's switch vs. Scala's match
And here is a list of stuff that you will probably use from the Java standard library, even if you develop in Scala:
IO
GUI (Scala has a wrapper for Swing, but hey)
URLs, URIs, files
date
timers
And finally, some of Scala's features that have no direct equivalent in Java or the Java standard library:
operator overloading
implicits and implicit conversions
multiple argument lists / currying
anonymous functions / functions as values
actors
streams
Scala pattern matching (which rocks)
traits
type inference
for comprehensions
awesome collection operations like fold or map
Of course, all the lists are incomplete. That's just my view on what is important. I hope it helps.
And, by the way: You should definitely know about the class path and other JVM basics.
The standard library, above all else, because that's what Scala has most in common with Java.
You should also get a basic idea of Java's syntax, because a lot of books end up comparing something in Scala to something in Java. But other than the platform and some of the library, they're totally distinctive languages.
There are a few trivial conventions passed from one to the other (like command line options), but as you read books and tutorials on Scala you should pick those up as you go regardless of previous Java experience.
The serie "Scala for Java Refugees" can gives some indications on typical Java topics you are supposed to know and how they translate into Scala.
For instance, the very basic main() Java function which translate into the Application trait, once considered harmful, and now improved (for Scala 2.9 anyway).