I have written a JAVA library for pi calculus which utilizes Deuce STM for managing concurrent processes.
I further wish to prove the type safety of my library.
Is Deuce STM library type safe? If yes, some links for the same would be appreciated.
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.
I'm lifting a native API to Scala. There appear to be two paths: use JNI or use Scala Native.
JNI usage creates the methods you want in Java and then shadows them in C where you write C code to access your API. Pro: you can use the native API's data structures directly. Con: your Scala code now also has to provide its own native wrapper library increasing chances of portability complications, and now you wrapped the library twice, once in JNI C to get it into the JVM and then in the Java/Scala module. A lot of work, many places for bugs. I used this path many times, I figured it was the way the world was.
Then along comes Scala native which does the reverse and shadows the C functions in Scala. Pro: you don't write in C so no new native library and no double wrapper. Con: it seems you can only lift Scala native primitives so complex native data structures can't be accessed. That makes the native library useless if it can't use its data structures.
Neither is terribly portable, as expected, but is there some functionality I'm over looking that fixes the cons of one or both of these approaches? Or some other reason to pick on Scala native over JNI?
Scala Native does not "shadow" C functions in JVM-based Scala. Scala Native is the direct equivalent of bare-metal/native C language but with Scala syntax instead of C syntax and Scala semantics (without any JVM-based semantics) instead of C semantics. If you were to chose JNI, then you would conceivably have 2 choices in the scope of your question of which language to utilize to invoke the JNI injections into the JVM from outside the JVM: either C or Scala Native. If you were to choose Scala Native to write UI code on a JVM-based infrastructure (e.g., Android) then you would be effectively choosing JNI as well by having Scala Native invoke JNI (instead of C invoking JNI). (All mentioning of C here applies to C++ as well.) All that said, utilizing Scala Native invoking JNI to perform UI function invocation from outside the JVM is highly unorthodox (and utilized widely only in the Xamarin-based world).
Scala native has been recently released, but the garbage collector they used (for now) is extremely rudimentary and makes it not suitable for serious use.
So I wonder: why not just transpile Scala to Go (a la Scala.js)? It's going to be a fast, portable runtime. And their GC is getting better and better. Not to mention the inheritance of a great concurrency model: channels and goroutines.
So why did scala-native choose to go so low level with LLVM?
What would be the catch with a golang transpiler?
There are two kinds of languages that are good targets for compilers:
Languages whose semantics closely match the source language's semantics.
Languages which have very low-level and thus very general semantics (or one might argue: no semantics at all).
Examples for #1 include: compiling ECMAScript 2015 to ECMAScript 5 (most language additions were specifically designed as syntactic sugar for existing features, you just have to desugar them), compiling CoffeeScript to ECMAScript, compiling TypeScript to ECMAScript (basically, after type checking, just erase the types and you are done), compiling Java to JVM byte code, compiling C♯ to CLI CIL bytecode, compiling Python to CPython bytecode, compiling Python to PyPy bytecode, compiling Ruby to YARV bytecode, compiling Ruby to Rubinius bytecode, compiling ECMAScript to SpiderMonkey bytecode.
Examples for #2 include: machine code for a general purpose CPU (RISC even more so), C--, LLVM.
Compiling Scala to Go fits neither of the two. Their semantics are very different.
You need either a language with powerful low-level semantics as the target language, so that you can build your own semantics on top, or you need a language with closely matching semantics, so that you can map your own semantics into the target language.
In fact, even JVM bytecode is already too high-level! It has constructs such as classes that do not match constructs such as Scala's traits, so there has to be a fairly complex encoding of traits into classes and interfaces. Likewise, before invokedynamic, it was actually pretty much impossible to represent dynamic dispatch on structural types in JVM bytecode. The Scala compiler had to resort to reflection, or in other words, deliberately stepping outside of the semantics of JVM bytecode (which resulted in a terrible performance overhead for method dispatch on structural types compared to method dispatch on other class types, even though both are the exact same thing).
Proper Tail Calls are another example: we would like to have them in Scala, but because JVM bytecode is not powerful enough to express them without a very complex mapping (basically, you have to forego using the JVM's call stack altogether and manage your own stack, which destroys both performance and Java interoperability), it was decided to not have them in the language.
Go has some of the same problems: in order to implement Scala's expressive non-local control-flow constructs such as exceptions or threads, we need an equally expressive non-local control-flow construct to map to. For typical target languages, this "expressive non-local control-flow construct" is either continuations or the venerable GOTO. Go has GOTO, but it is deliberately limited in its "non-localness". For writing code by humans, limiting the expressive power of GOTO is a good thing, but for a compiler target language, not so much.
It is very likely possible to rig up powerful control-flow using goroutines and channels, but now we are already leaving the comfortable confines of just mapping Scala semantics to Go semantics, and start building Scala high-level semantics on top of Go high-level semantics that weren't designed for such usage. Goroutines weren't designed as a general control-flow construct to build other kinds of control-flow on top of. That's not what they're good at!
So why did scala-native choose to go so low level with LLVM?
Because that's precisely what LLVM was designed for and is good at.
What would be the catch with a golang transpiler?
The semantics of the two languages are too different for a direct mapping and Go's semantics are not designed for building different language semantics on top of.
their GC is getting better and better
So can Scala-native's. As far as I understand, the choice for current use of Boehm-Dehmers-Weiser is basically one of laziness: it's there, it works, you can drop it into your code and it'll just do its thing.
Note that changing the GC is under discussion. There are other GCs which are designed as drop-ins rather than being tightly coupled to the host VM's object layout. E.g. IBM is currently in the process of re-structuring J9, their high-performance JVM, into a set of loosely coupled, independently re-usable "runtime building blocks" components and releasing them under a permissive open source license.
The project is called "Eclipse OMR" (source on GitHub) and it is already production-ready: the Java 8 implementation of IBM J9 was built completely out of OMR components. There is a Ruby + OMR project which demonstrates how the components can easily be integrated into an existing language runtime, because the components themselves assume no language semantics and no specific memory or object layout. The commit which swaps out the GC and adds a JIT and a profiler clocks in at just over 10000 lines. It isn't production-ready, but it boots and runs Rails. They also have a similar project for CPython (not public yet).
why not just transpile Scala to Go (a la Scala.js)?
Note that Scala.JS has a lot of the same problems I mentioned above. But they are doing it anyway, because the gain is huge: you get access to every web browser on the planet. There is no comparable gain for a hypothetical Scala.go.
There's a reason why there are initiatives for getting low-level semantics into the browser such as asm.js and WebAssembly, precisely because compiling a high-level language to another high-level language always has this "semantic gap" you need to overcome.
In fact, note that even for lowish-level languages that were specifically designed as compilation targets for a specific language, you can still run into trouble. E.g. Java has generics, JVM bytecode doesn't. Java has inner classes, JVM bytecode doesn't. Java has anonymous classes, JVM bytecode doesn't. All of these have to be encoded somehow, and specifically the encoding (or rather non-encoding) of generics has caused all sorts of pain.
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)
I'm wondering why Scala does not have an IO Monad like Haskell.
So, in Scala the return type of method readLine is String whereas in Haskell the comparable function getLine has the return type IO String.
There is a similar question about this topic, but its answer it not satisfying:
Using IO is certainly not the dominant style in scala.
Can someone explain this a bit further? What was the design decision for not including IO Monads to Scala?
Because Scala is not pure (and has no means to enforce that a function is pure, like D has) and allows side effects. It interoperates closely with Java (e.g. reuses big parts of the Java libraries). Scala is not lazy, so there is no problem regarding execution order like in Haskell (e.g. no need for >> or seq). Under these circumstances introducing the IO Monad would make life harder without gaining much.
But if you really have applications where the IO monad has significant advantages, nothing stops you from writing your own implementation or to use scalaz. See e.g. http://apocalisp.wordpress.com/2011/12/19/towards-an-effect-system-in-scala-part-2-io-monad/
[Edit]
Why wasn't it done as a lazy and pure language?
This would have been perfectly possible (e.g. look at Frege, a JVM language very similar to Haskell). Of course this would make the Java interoperability more complicate, but I don't think this is the main reason. I think a lazy and pure language is a totally cool thing, but simply too alien to most Java programmers, which are the target audience of Scala. Scala was designed to cooperate with Java's object model (which is the exact opposite of pure and lazy), allowing functional and mixed functional-OO programming, but not enforcing it (which would have chased away almost all Java programmers). In fact there is no point in having yet another completely functional language: There is Haskell, Erlang, F# (and other MLs) and Clojure (and other Schemes / Lisps), which are all very sophisticated, stable and successful, and won't be easily replaced by a newcomer.