Scala blogs aggregated
by Lalit Pant (noreply@blogger.com) at May 16, 2012 04:33 AM
Tumblr Integration
This version of Herald is ported to use the Tumblr API for posting and is configured to publish to notes.implicit.ly by default. The “notes” subdomain is the new home of implicit.ly release notes and redirects are in place.
Upgrade and Authorization
You can upgrade Herald…
The old switcheroo.
Light Table - a new IDE (by Chris Granger)
This version adds new features on top of 1.9:
skipAllUnless(condition) to skip examples unless a condition is verified
CommandLineArguments trait to access the command-line arguments and use them to build the specification or to specialize the examples behaviour
notoc argument to avoid generating a table of contents
css/specs2-user.css file to customize the display of the html documentation
include(childSpec.hide)
class S extends Specification { def is = "Guide".title.baseDirIs("guide") ^ end }
Error thrown from an Example (see this StackOverflow question)
And some fixes:
AssertionError with a null message
==========================
specs2 is a library for writing software specifications in Scala.
For more information visit: http://specs2.org.
A minor release of shapeless. The main changes include,
Scrap Your Boilerplate improvements
shapeless is an exploration of type class and dependent type based generic programming in Scala.
A series of articles on the implementation techniques used will appear here and it also has a mailing list.
X-Http-Method-Override header.
SIP-18 is a bad idea because it makes awful assumptions about what is in the interest of language newcomers. I have had no shortage of unsolicited advice of how to teach, most of it in layers of wrongness, so I am acutely aware of the sheer quantity of this kind of advice. Please refrain for now. This is only my opinion, because it has been asked of me more than twice.
SIP-18 (and the Scala collections library for that matter) is no different to Haskell’s (dreaded) monomorphism restriction (DMR). The DMR was introduced specifically because of another chronically bold over-estimate of one’s ability to understand the process of learning. It is now an undesired language issue that hinders all users, especially newcomers. In other words, it serves nobody’s interest, hinders everyone’s interest and especially, the interest of those for whom it was meant to serve. You need only spend a short period of time with newcomers to Haskell to be overwhelmed by the prominence of this fact.
I can hear the pragmatists in the background muttering something about trade-offs, not being so extreme and keeping it relevant to the real world and blah blah blah, <insert the usual pragmatist bullshit here>. There is nothing to be traded off when you offer to take $5 from me for the low cost of $10. Now stop it and get your head out of the clouds so I can talk to you sensibly.
Not only does SIP-18 not help newcomers at all, it helps nobody, hinders everybody and especially newcomers. It is not a trade-off, it is not a good idea; it is simply a bold, severely misguided assertion about how learning takes place — it’s not even an approximation. I have seen only scant pseudo-psychology to support its existence, which obviates its predictable failure.
Hopefully, the Scala guys will work this out, but if Scala’s remarkable precision to repeat historical mistakes is anything to go by, I do not hold high hopes.
Thanks for asking.
A few days back the Scala IDE team released an early preview of the Scala IDE V2.1 for Eclipse, based on the new milestone (M3) for the upcoming Scala 2.10. This release has all the new features in the Scala IDE M1, plus a few minor changes needed in order to support 2.10.
You can see the Release Notes for M1 to check the new features in the Scala IDE, and the Scala Change Log for what’s new in Scala 2.10. Read more...
by Jesper Nordenberg (noreply@blogger.com) at May 09, 2012 10:18 PM
This is a feature release, adding a the full set of useful XPath Axe, string based XPath evaluation - via a popular open source XPath library, useful equality testing, a lot of new documentation and many smaller improvements in syntax and usability.
This version has been built with xsbt 0.11.x and migrated to github. This releases documentation can be found here and provides many examples on how to use Scales Xml.
Scales 0.3 adds the following axe:
This provides all of the XPath 1 and 2 axe (namespace axis excluded).
position() (pos)
pos\_<, pos\_==, pos\_>
last() (last)
last\_<, last\_==, last\_>
Easier to extend and re-use queries and axe
xfilter, xmap, xflatMap
Implementations for all relevant Scales Xml types
XmlComparison type classes provide full details of differences:
Scales 0.3 moves to Sonatype under the organisation org.scalesxml, with support for 2.8.1, 2.8.2, 2.9.1 and 2.9.2. As such add:
libraryDependencies ++= Seq( // just for the core library "org.scalesxml" %% "scales-xml" % "0.3-RC6" // or, use this instead for String based XPaths (Jaxen, also includes the core) "org.scalesxml" %% "scales-jaxen" % "0.3-RC6" )
to your xsbt builds or use scales-xml_2.9.2 as the id when using Maven.
Scales Xml is an alternate xml library for Scala providing a coherent model, querying and manipulation via an XPath like syntax, better performance, highly customisable equality framework and an Iteratee based pull api.
buildInfoBuildNumber. #2
sbt-buildinfo is a plug-in for sbt to generate Scala source from your build definitions.
sbt-assembly is a plug-in for Simple Build Tool that creates a single jar of your project including all of its dependencies.
--quiet, --recurse, --stdin, --stdout options to command-line tool
5.f, 5.d as floating points, unless in Scala 2.11+ mode
--scalaVersion=<version> flag to command-line tool
expr[T1, T2][T3, T4] and g()[String] syntaxes
Scalariform is a source code formatter for Scala.
Small maintenance release, including:
FileNotFoundException is thrown
(issue #8) -- Martin Konicek
NoSuchElementException with a message
clearly refering to the missing key (issue #11) -- Jussi Virtanen
If you wish for extra features, feel free to ask.
Configrity is a simple, immutable and flexible Scala API for handling configurations.
This substantial contribution by g-eorge handles file of uploads of arbitrary size, as previously supported only for filter plans. See the netty-uploads readme for details.
Migration Note: If you were using the unfiltered-uploads module before, you should now depend on unfiltered-filter-uploads. The former now serves as a base implementation for the filter and netty upload modules.
HttpRequest object in the older fashion of Unfiltered. This is altered to now only yield the charset, which is a breaking change. If you see a compilation error for a Charset matcher, simply remove the trailing prameter in its parameter list. Unfiltered is a toolkit for servicing HTTP requests in Scala.
by Tim Azzopardi (noreply@blogger.com) at May 06, 2012 10:17 PM
flatMap Oslo (May 15, 16) is Norway’s first Scala conference, and the first anywhere to have such exciting light fixtures. (Good speaker lineup, too.)
Java: Call an anonymous PLSQL Block with one input string and one output string parameter and one output cursor (query result) parameter :
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Types;
public class CallPLSQLBlockWithOneInputStringAndOneOutputStringParameter {
// Warning: this is a simple example program : In a long running application,
// exception handlers MUST clean up connections statements and result sets.
public static void main(String[] args) throws SQLException {
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
final Connection c = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "system", "manager");
String plsql = "" +
" declare " +
" p_id varchar2(20) := null; " +
" begin " +
" p_id := ?; " +
" ? := 'input parameter was = ' || p_id;" +
" end;";
CallableStatement cs = c.prepareCall(plsql);
cs.setString(1, "12345");
cs.registerOutParameter(2, Types.VARCHAR);
cs.execute();
System.out.println("Output parameter was = '" + cs.getObject(2) + "'");
cs.close();
c.close();
}
}
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Types;
import oracle.jdbc.OracleTypes;
public class CallPLSQLBlockWithOneInputStringAndOneOutputStringParameterAndOneOutputCursorParameter {
public static void main(String[] args) throws Exception {
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
final Connection c = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "system", "manager");
String plsql = "" +
" declare " +
" p_id varchar2(20) := null; " +
" l_rc sys_refcursor;" +
" begin " +
" p_id := ?; " +
" ? := 'input parameter was = ' || p_id;" +
" open l_rc for " +
" select 1 id, 'hello' name from dual " +
" union " +
" select 2, 'peter' from dual; " +
" ? := l_rc;" +
" end;";
CallableStatement cs = c.prepareCall(plsql);
cs.setString(1, "12345");
cs.registerOutParameter(2, Types.VARCHAR);
cs.registerOutParameter(3, OracleTypes.CURSOR);
cs.execute();
System.out.println("Result = " + cs.getObject(2));
ResultSet cursorResultSet = (ResultSet) cs.getObject(3);
while (cursorResultSet.next ())
{
System.out.println (cursorResultSet.getInt(1) + " " + cursorResultSet.getString(2));
}
cs.close();
c.close();
}
}
import java.sql.Array;
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Types;
import oracle.jdbc.OracleTypes;
import oracle.sql.ARRAY;
import oracle.sql.ArrayDescriptor;
public class CallPLSQLBlockWithOneInputStringArrayAndOneOutputStringParameterAndOneOutputCursorParameter {
public static void main(String[] args) throws Exception {
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
// Warning: this is a simple example program : In a long running application,
// error handlers MUST clean up connections statements and result sets.
final Connection c = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "system", "manager");
String plsql = "" +
" declare " +
" p_id string_array := null; " +
" l_rc sys_refcursor;" +
" begin " +
" p_id := ?; " +
" ? := 'input parameter first element was = ' || p_id(1);" +
" open l_rc for select * from table(p_id) ; " +
" ? := l_rc;" +
" end;";
String[] stringArray = new String[]{ "mathew", "mark"};
// MUST CREATE THIS IN ORACLE BEFORE RUNNING
System.out.println("(This should be done once in Oracle)");
c.createStatement().execute("create or replace type string_array is table of varchar2(32)");
ArrayDescriptor descriptor = ArrayDescriptor.createDescriptor( "STRING_ARRAY", c );
Array array_to_pass = new ARRAY( descriptor, c, stringArray );
CallableStatement cs = c.prepareCall(plsql);
cs.setArray( 1, array_to_pass );
cs.registerOutParameter(2, Types.VARCHAR);
cs.registerOutParameter(3, OracleTypes.CURSOR);
cs.execute();
System.out.println("Result = " + cs.getObject(2));
ResultSet cursorResultSet = (ResultSet) cs.getObject(3);
while (cursorResultSet.next ())
{
System.out.println (cursorResultSet.getString(1));
}
cs.close();
c.close();
}
}
import java.sql.Array;
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Types;
import oracle.jdbc.OracleTypes;
import oracle.sql.ARRAY;
import oracle.sql.ArrayDescriptor;
import oracle.sql.STRUCT;
import oracle.sql.StructDescriptor;
public class CallPLSQLBlockWithOneInputStructureArrayAndOneOutputStringParameterAndOneOutputCursorParameter {
public static void main(String[] args) throws Exception {
DriverManager.registerDriver(new oracle.jdbc.OracleDriver());
// Warning: this is a simple example program : In a long running application,
// error handlers MUST clean up connections statements and result sets.
final Connection c = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "system", "manager");
String plsql = "" +
" declare " +
" p_id student_array := null; " +
" l_rc sys_refcursor;" +
" begin " +
" p_id := ?; " +
" ? := 'input parameter first element was = (' || p_id(1).id_num || ', ' || p_id(1).name || ')'; " +
" open l_rc for select * from table(p_id) ; " +
" ? := l_rc;" +
" end;";
// MUST CREATE ORACLE TYPES BEFORE RUNNING
setupOracleTypes(c);
StructDescriptor structDescr = StructDescriptor.createDescriptor("STUDENT", c);
STRUCT s1struct = new STRUCT(structDescr, c, new Object[]{1, "mathew"});
STRUCT s2struct = new STRUCT(structDescr, c, new Object[]{2, "mark"});
ArrayDescriptor arrayDescr = ArrayDescriptor.createDescriptor( "STUDENT_ARRAY", c );
Array array_to_pass = new ARRAY( arrayDescr, c, new Object[]{s1struct, s2struct} );
CallableStatement cs = c.prepareCall(plsql);
cs.setArray( 1, array_to_pass );
cs.registerOutParameter(2, Types.VARCHAR);
cs.registerOutParameter(3, OracleTypes.CURSOR);
cs.execute();
System.out.println("Result = " + cs.getObject(2));
ResultSet cursorResultSet = (ResultSet) cs.getObject(3);
while (cursorResultSet.next ())
{
System.out.println (cursorResultSet.getInt(1) + " " + cursorResultSet.getString(2));
}
cs.close();
c.close();
}
private static void setupOracleTypes(final Connection c)
throws SQLException {
System.out.println("(This should be done once in Oracle)");
try {
c.createStatement().execute("drop type student_array ");
} catch (Exception e) {
// ignore
}
c.createStatement().execute("create or replace type student as object (id_num integer(4), name varchar2(25))");
c.createStatement().execute("create or replace type student_array is table of student");
}
}
by Tim Azzopardi (noreply@blogger.com) at May 05, 2012 09:09 PM
CLI users can upgrade using cs by running the following command:
`
cs philcali/robot-vision
`
Robot Vision Control (RVC) is an embedded unfiltered web server allowing remote control over the host machine similar to RDP and VNC, except control is handled at the http transport layer.
RVC's source is hosted on github. Detailed installation and usage information can be found in the project's README.
Chrome browsers and Chromebooks can take advantage of the extension for subvert control connections and managing host URL's. Conveniently install the extension at the Chrome webstore.
In the previous blog post I claimed that Functors, Monads and Applicatives can be presented in an easily comprehensible way:
a) ( A=>B ) => ( C[A]=>C[B] ) | Functor
b) ( A=>C[B] ) => ( C[A]=>C[B] ) | Monad
c) ( C[A=>B] ) => ( C[A]=>C[B] ) | Applicative
Thus they are perceived as transformations/conversions from some function type involving an A and a B to the type C[A]=>C[B] .
We then created a container MyBox, which can keep a value of some type, and some functions which implemented the above mentioned signatures.
For example the Functor transformation was implemented as a standalone function named map :
def map[A,B]( rawfunc:A=>B ) : MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox( rawfunc(a.value) )
But what I want you to understand in this post, is that this -map as a function taking a function- is only one possible implementation, and that there are very different ways to structure the concept represented by the function map . This is much more true for Scala, which is a feature rich hybrid OO-FP language. To demonstrate this, let’s stay with Functors and the shown map function. What you see here will be applicable for the other concepts, Monad and Applicative, too.
First, let us again have a look at the signature of map:
( A=>B ) => ( MyBox[A]=>MyBox[B] )
According to this signature, map takes a function of type A=>B and returns a function which takes a MyBox[A]. In the end the result is of type MyBox[B]. The second pair of parens can easily be left out:
( A=>B ) => MyBox[A] => MyBox[B]
What we now see is a curried form that we can transform back into a multi-parameter function:
((A=>B), MyBox[A]) => MyBox[B]
We now have a function taking two parameters -a function A=>B and a MyBox[A]- and resulting in MyBox[B]. In such a case the order of the parameters isn’t really important, so we can change that easily to
( MyBox[A],(A=>B)) => MyBox[B]
what in curried form again is
MyBox[A] => (A=>B) => MyBox[B]
Let’s take our first implementation and adapt that according to this signature:
def map[A,B](a:MyBox[A]): (A=>B)=>MyBox[B] = (rawfunc:A=>B) => new MyBox( rawfunc(a.value) )
Now map first takes the container to work on and then returns a function that is bound to that container, but expects as parameter the bare typed function which shall be applied to produce the result.
This is a signature for map that you will also find in articles, either as a primary way to implement it, or as a helper function, delegating to the other signature (like here).
So far the class MyBox and the function map are only loosely related, i.e. the function map can be located anywhere in our code base. To organize it better and document the relationship of map with MyBox, we could possibly declare it as a method on a companion object:
object MyBox {
def map[A,B](a:MyBox[A]): (A=>B)=>MyBox[B] = (rawfunc:A=>B) => new MyBox( rawfunc(a.value) )
}
Much more, if we have a function that takes an instance of some class as its first parameter, this is only a functional way to describe a method, which in classical OO would belong to the class itself. So the signature
(MyBox[A],(A=>B)) => MyBox[B]
is a hint, that maybe map should be implemented like this:
class MyBox[A](val value:A) {
def map[A,B](rawfunc:A=>B) = new MyBox( rawfunc(this.value) )
}
So now we can call map directly on an instance of MyBox:
val n = new MyBox("hello")
n.map( (a:String)=>a.length ).value // -> 5
This is a nice way to implement Functors and Monads in case you are the class’ author and have such features already in mind. As you may know, Scala’s for-comprehension is only syntactic sugar for calls to map and flatMap on instances. Therefore our class can be used inside such expressions too.
Another Scala-typical way to provide methods on objects although their class does not implement them are wrapper classes and implicit conversions. How this would look like for our MyBox, you see below, including also the Monad method flatMap.
class MyBox[T](val value:T) {
override def toString() = "MyBox("+value+")"
}
class MyBoxWrapper[T](w:MyBox[T]) {
def flatMap[R](f:T=>MyBox[R]) = map(f).value
def map[R](f:T=>R) = new MyBox(f(w.value))
}
object TestMonadWrapper {
implicit def myBoxToWrapper[S](mb:MyBox[S]) = new MyBoxWrapper[S](mb)
def main(args:Array[String]) {
val ma = new MyBox("hello world")
println ( ma.map((a) => a.length) )
val res = for {
a <- ma
} yield a.length + 2
println(res)
val mb = new MyBox("hola mundo")
val res2 = for {
a <- ma
b <- mb
} yield a.size + b.size
println (res2)
}
}
This is an extended example, so let’s have a walk-through. Class MyBox implements a toString Method to allow for convenient printing on console, so we don’t have to call .value to see what the value is. MyBox does not implement the methods map and flatMap itself, but we have a wrapper class MyBoxWrapper that implements them for us. Our application object TestMonadWrapper contains some tests in the main method, and an implicit conversion that wraps a MyBox instance into a MyBoxWrapper whereever the methods map and flatMap are called on a MyBox instance. This is the case for ma and mb inside the for-comprehensions.
Last but not least Scala also knows typeclasses -not as a language feature but as a pattern-, which are just another way to provide function implementations for specific types, a concept taken from Haskell. I don’t want to dive into that matter here now. To see Monads implemented as a typeclass, have a look into Daniel Spiewak’s article Monads are not metaphors , where the concept Monad is shown as a trait, implemented by two implicit objects for different types, or at Eric Torreborre’s article The Essence of the Iterator Pattern, where he demonstrates Functor and Applicative as typeclasses right from the beginning.
In my examples you have so far always seen the functions named map, flatMap and apply. The first two match with how the Scala standard library is implemented and the for-comprehension works. But the name apply must be taken with care, as this is in Scala a conventional method to use object references like functions.
Indeed, other languages implement the concepts of Functor, Monad and Applicative too but use other names for the functions. Namely in Haskell, the source of those ideas, the methods are named differently and sometimes confusingly for a Scala developer. So is the method map named fmap there, not to be confused with Scala’s flatMap, which is named bind in Haskell. Beside that, Haskell uses even symbolic names for the functions.
Another blog post which I found recently and which presents Functors, Monads and Applicatives in a similar reduced way like my first post, is Functors, Applicative Functors, and Monads aren’t that scary. The author took the Haskell function names for Scala too.
All in all, the names are of no importance. Much more, have a look at the signatures to recognise the patterns shown in the first post, even when they are mutated, like seen in this post.
In the next post we will look at the three function signatures of the first post again, and think about how it comes that we would need flatMap and apply.
After a recent discussion on the Scala-Internals mailing list on the pros and cons of methods that take boolean arguments, the consensus was that they should always be passed as named arguments. The compiler doesn’t enforce this, so it’s up to us IDE and tools developers to provide a solution. The code-analysis branch for the Eclipse Scala IDE can now warn you of such boolean arguments that are passed to Scala methods:
The warning comes with a quick-fix that inserts the parameter name:
Of course, the competition isn’t sleeping either, the IntelliJ Scala plug-in just got a bunch of new Intentions.
The MarkWrap library (pronounced "mark wrap" or "more crap", depending on your preference) is a Scala library that provides a unified API for using various underlying lightweight markup APIs. Currently, it supports:
<pre> and </pre> tags.
See the MarkWrap web site for more details.
The org.clapper.classutil (ClassUtil) library is a Scala package that provides various class location and class generation capabilities, including:
See http://software.clapper.org/classutil/ for details.
The Grizzled SLF4J package provides a very thin Scala-friendly layer on top of the SLF4J (Simple Logging Facade for Java) API.
AVSL is a very simple logger, written in Scala. AVSL implements the Simple Logging Facade for Java (SLF4J) API, allowing applications to be written to the SLF4J API, for portability. It uses a simple, non-XML configuration file.
Argot is a command-line parser library for Scala, supporting:
tar -xcf foo.tgz")
You can find complete details, including usage information, on the Argot home page.
The Grizzled Scala Library contains a variety of miscellaneous utility classes and objects. Basically, whenever I find myself writing something that's general-purpose, I put it in here, so I can easily use it in multiple projects.
A minor release of shapeless. The main changes include,
Improved build configuration,
shapeless is an exploration of type class and dependent type based generic programming in Scala.
A series of articles on the implementation techniques used will appear here and it also has a mailing list.
TYPE_TUPLE(type) is called with one element. #14 reported by @psnively
TYPE_EITHER(typ1, typ2), TYPE_LEFT(typ1, typ2), TYPE_RIGHT(typ1, typ2).
RIGHT(tree) and LEFT(tree).
treehugger.scala is a library to code Scala programmatically.
$ git branch feature #create the working branch $ git checkout feature #do all development work on that branch #Edit files, etc. $ git commit -m "Implement Feature" #Repeat the above as desired during development. #When ready to merge to master, do the following: $ git checkout master $ git pull #update master from shared repository $ git checkout feature $ git rebase master #optionally with -i if squashing is desired $ git checkout master $ git merge feature $ git push origin master $ git branch -d featureBecause we never use our local master branch for development, the git pull on master is always a fast-forward merge. Likewise, because we have just rebased the feature branch against the master right before we merge that feature branch back into master, that merge is also always a fast-forward merge. Looking at it another way, we don't have any merge conflicts when updating or merging master because we resolve all of the merge conflicts when we rebase the feature branch against the latest master.
$ git rebase 8bc85584989e4435c2d98b13447bcab37648ba7fIf this rebase reports no merge conflicts, then I try rebasing against master and repeat the process.
by Jim McBeath (noreply@blogger.com) at May 01, 2012 05:40 AM
A new milestone release for Scala is now available. This release is cut directly from current development and is not intended for production environments, but is a great chance to try out the up and coming features for Scala 2.10.0. The milestone 2.10.0-M3 includes many fixes and improvements, listed below.
This release improves support for github OAuth. The previous release
did not request the proper scope for private repositories. If you
already obtained a token, or wish to switch from name and password
auth, then run g8 with your github name and password separated by
a : character:
g8 --auth yourname:yourpass
If successful, this command stores an access token in ~/.g8/config
which is used for all future g8 invocations. You can revoke tokens
at any time in your github account settings.
To upgrade giter8 using Conscript:
cs n8han/giter8
giter8 is a command line tool to apply templates defined on github
This version includes the following improvements:
verify at the end of each ScallopConf object - it now happens auto-magically
Scallop is a simple (yet powerful) command-line arguments parsing library for Scala.
When I started trying to get into these weird topics named “functors” and “monads” and so on, which came up in the Scala mailing list, I was more than slightly confused [1]. I read some articles (in the beginning not many existed), listened to mails, consulted book chapters, and even started learning Haskell to consult the very fine “Learning a Haskell for great good” chapters on that matters. Different authors use different ways to explain -and implement!- these concepts, what in the end is helpful. You can read an article, think, read some other perspective, come back to the first article again, a.s.o.
But it took some time to realise how darn simple it all can be in principle (and took more time to finally write about it). I worked with and restructured some examples until the simplicity of it all became obvious. So let me now present you my perspective on it, and perhaps it will help you to get into these seemingly strange things:
Given some type constructor C[_] and two types A and B, we want to apply functions of type C[A]=>C[B] .
Unfortunately we have only functions of types A=>B, A=>C[B] and C[A=>B] at hand, so we need adequate transformations for them:
a) ( A=>B ) => ( C[A]=>C[B] )
b) ( A=>C[B] ) => ( C[A]=>C[B] )
c) ( C[A=>B] ) => ( C[A]=>C[B] )
All these are transformations of some given functions into the function type we need, and all these transformations even have names.
a) ( A=>B ) => ( C[A]=>C[B] ) | Functor
b) ( A=>C[B] ) => ( C[A]=>C[B] ) | Monad
c) ( C[A=>B] ) => ( C[A]=>C[B] ) | Applicative
That is the pattern we have to learn by heart and keep in mind. All other is simply applying that pattern, present it in different forms and implementations [2].
Too fast? Too abstract?
Ok, now that you surely have learned this scheme by heart and can reproduce it without spiking into this article, we’ll have a closer look at how and why that works.
It all starts with a container of some type C, which is able to hold one or more values of some type A. So we have C[A] to start with.
The container itself can serve different purposes. We will come back to that in a follow-up post.
To keep things easy for now, let’s start with the most simple: A box.
class MyBox[T](val value:T)
Then we can put a value of some type into such a box, for example a string.
val boxedstring:MyBox[String] = new MyBox("Hello")
Now we want to apply some computation or transformation on the value (type A) in C, without leaving C. That means, the result value of some type B shall also be in a C. In other words: We want to apply functions of type C[A]=>C[B].
In our example: Let’s assume we want to compute the length of the string in MyBox, and get the result again in MyBox. This would need a function of type MyBox[String] => MyBox[Int], which would calculate the lenght but somehow stay inside the box:
def lengthOf( a:MyBox[String]) : MyBox[Int] = ....
The problem is that we already have some interesting computations -like the length of a string- at hand, but they are not of the correct type. They are of much more functions on the raw types A=>B, or functions of type A=>C[B] or even the raw functions already wrapped in C, resulting in C[A=>B] (Why that is, we talk about later).
In our example, we have a function:
def rawLengthOf(a:String) : Int = a.length
We can see, that we need to transform it. So let’s write a transformation for it:
def map[A,B]( rawfunc:A=>B ) : MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox( rawfunc(a.value) )
Let’s look closer into it: map is a function that takes another function of the raw types A=>B as parameter and returns a new function that takes a MyBox[A], applies the raw function, and wraps the result in a MyBox again.
Now let us put all these things together:
class MyBox[T](val value:T)
def map[A,B]( rawfunc:A=>B ) : MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox( rawfunc(a.value) )
val boxedstring:MyBox[String] = new MyBox("Hello") // a boxed value
def rawLengthOf(a:String) : Int = a.length // the raw function we want to use
val transformedLenghtOf = map(rawLenghtOf) // applying the transformation, so we get our new function
val result:MyBox[Int] = transformedLengthOf( boxedstring ) // applying the new function
So we have a MyBox[_], and we have a map function for MyBox. Congratulations, this is your first Functor!
The other two examples work similarly.
We start with our boxedstring again, but then we have:
def lengthOf(a:String) = new MyBox( a.length ) // a function which takes a raw type but boxes the result itself
Why such things can happen, we will see later.
So we need a new transformation:
def flatMap[A,B]( func:A=>MyBox[B] ): MyBox[A]=>MyBox[B] = (a:MyBox[A]) => func( a.value )
flatMap is a function that takes a semi-raw function of type A=>MyBox[B] -e.g. String=>MyBox[Int]-, and returns a new function that takes a MyBox[A], applies the semi-raw function and simply returns its result.
The rest now looks almost the same:
val transformedLenghtOf = flatMap(lenghtOf) // applying the transformation, so we get our new function val result:MyBox[Int] = transformedLengthOf( boxedstring ) // applying the new function
Again: We have a MyBox[_], and we have a flatMap function for MyBox.
This, my dear, is a Monad!
The third pattern shouldn’t be much of a problem here.
Again we start with our boxedstring, but now we found our rawLengthOf again, surprisingly itself boxed in a MyBox:
val boxedLengthOf:MyBox[String=>Int] = new MyBox( rawLengthOf _ )
But this is no problem, we only need another converter, this time without any “map” in its name.
def apply[A,B](b:MyBox[A=>B]): MyBox[A]=>MyBox[B] = (a:MyBox[A]) => new MyBox(b.value(a.value))
apply now is a function that takes a boxed raw function and returns a new function that takes a MyBox[A], applies the unboxed raw function to its unboxed value, and returns the result in a new box.
val transformedLenghtOf = apply(boxedLenghtOf) // applying (*haha*) the transformation, to get our new function val result:MyBox[Int] = transformedLengthOf( boxedstring ) // applying the new function
Applicative on stage!
Let’s sum it up by listing all these transformations together. All transformations result in MyBox[A]=>MyBox[B], so I will leave this type away:
class MyBox[T](val value:T) //Functor def map[A,B] ( rawfunc:A=>B ) = (a:MyBox[A]) => new MyBox( rawfunc(a.value) ) // Monad def flatMap[A,B]( func:A=>MyBox[B] ) = (a:MyBox[A]) => func( a.value ) // Applicative def apply[A,B] ( b:MyBox[A=>B] ) = (a:MyBox[A]) => new MyBox(b.value(a.value))
So far for the basic stuff. In the next article we will talk about alternative ways to implement such concepts in Scala, so we are able to recognise them, no matter how they are implemented or how the transformation functions are named.
[1] “A Monad is a monoid in the category of endofunctors” became a popular term of debate about the usefulness of such explanations.
[2] Well, there may be more about the theoretical concept of Functors, Monads and Applicatives -and Category Theory- but that is all you need to know to start.
Or: What happens when a simple number joke meets a bored Scala developer …
Save the following code into a file, e.g. named Fears.scala.
type Reason = () => String
class ReasonedState(val state:Boolean, val reason:Reason)
case class True(why:Reason) extends ReasonedState(true, why) {
override def toString() = "yes"
}
case class False(why:Reason) extends ReasonedState(false, why) {
override def toString() = "no"
}
class Fears(value:Int) {
def afraidOf(other:Int) = (value,other) match {
case (6,7) => True (() => (7 to 9).toList.map(_.toString).reduce(_+" "+_))
case _ => False(() => "nothing to fear")
}
}
implicit def numbersFears(nu:Int) = new Fears(nu)
def is(rs:ReasonedState) = rs
def y (rs:ReasonedState) = rs match {
case rs:True => "because "+rs.reason()
case _ => "wrong question"
}
Then open the Scala REPL in the same directory as the file you saved and type:
scala> :load Fears.scala
Now type:
scala > y ( is ( 6 afraidOf 7 ) )
…and enjoy the result.
Tip: If you don’t already know it, read the input and the result aloud (in english).
Many Scala training courses are now available, reflecting the constantly growing interest in the Scala programming language and its ecosystem. The courses that are now on offer include a range of introductory as well as advanced Scala training courses, as well as courses on Akka and Play, delivered by Typesafe and partners, by Underscore Consulting, by tune-it, Escalate Software, and others. You can find below a detailed list of opportunities to get professional Scala training close to your location.
@jorgeO Parachuted into into enemy territory
We need to teach our kids to code
At first I was worried Viktor did not have a funny t-shirt but then he took off his Akka hoodie.
@marius not talking about Futures
DataExpress talk
Robot Vision Control (RVC) is an embedded unfiltered web server allowing remote control over the host machine similar to RDP and VNC, except control is handled at the http transport layer.
The client is a Chrome extension. This is rad.
When writing Scala code that involves pattern matching I often work with (nested) case classes and sequences of case classes. I usually start with a simple binding like this
case class Person(firstName: String, lastName: String)
List(Person("Mirko", "Stocker")) match {
case person :: Nil =>; ...
}
and then when I need to access members of the matched class convert it to use the extractor:
List(Person("Mirko", "Stocker")) match {
case Person(firstName, lastName) :: Nil => ...
}
What’s tedious about that step is that one needs to know how many arguments there are and name all the bindings. But not for much longer! I wrote a quick-fix for the Scala IDE that does this for you:
Ctrl+1 brings up the available quick fixes:
And this is what happens when the binding you’re expanding is used in the pattern’s body:
It also works if you use a typed pattern where the type is a case class:
This feature isn’t in the recently released Milestone 1, but it should be part of the next one (or one of the upcoming nightly builds). Suggestions for a better wording – expand case class binding – are welcome 
Today we released an early preview of the Scala IDE V2.1 for Eclipse! While the goal of V2.0 was to provide a reliable environment for your Scala coding, with V2.1 we want to bring your Scala development experience to a whole new level.
In this milestone there are a whole lot of new features for you to try out: implicit highlight, move refactoring, scala debugger and semantic highlight are the most exciting ones. If you are like us, once you start using them you will no longer be able go back. They are simply too addictive!
A new stable release of Scala is available for download! Many thanks to all our contributors and testers. You can find the new Scala 2.9.2 on our Download Page. This new release addresses several bugs, and introduces additional improvements; you can find the full description below.
There are some features on Meetup that, while valuable, are enhancements to the core experience. We wouldn’t want these sometimes memory- and processor-intensive features to prevent someone from doing something as important as RSVPing to a Meetup. Because of this, these features have been…
Everybody needs a ListenableFuture interface.
Because github is terminating its v2 APIs on May 1, 2012 and these are used by all earlier versions of giter8, you must upgrade in order to continue using the software.
Go ahead and upgrade now, before you forget and github terminates the APIs and you open a bug against giter8 and I get even more annoyed about this whole situation.
A new Release Candidate in the Scala 2.9.x series is now available for download: 2.9.2 RC3. This release includes many bugfixes, as well as backported documentation and scaladoc improvements from the community.
This RC3 release candidate is made available for testing purposes only and is not intended for production environments: a final 2.9.2 release will follow at the end of the RC cycle. Please help us with the testing of this candidate, and let us know of any issues that you may encounter.
In the course of developing some Scala libraries that have stuck around, I’ve generally found it helpful to users if I release artifacts compatible with the two most recent major versions of Scala. So at the moment I support everything between 2.8.0 and 2.9.1-1.
Binary compatibility across minor Scala versions can lessen the burden, but as long as the language continues to evolve there will be transition periods where libraries must support more than one major version. Instead of scrambling to handle multiple publishing targets every time this happens, it’s safer and easier to handle them always with the automation known as cross-building. This feature of sbt runs a build against a set of Scala versions and publishes distinctive artifacts, so that sbt can also retrieve artifacts that are compatible with a particular version of Scala.
The same is true, it would seem, for test frameworks. You need to run tests against your own library for all the versions of Scala you claim compatibility with. If you can’t use your test framework with a Scala version, you’re out of luck—and so are your users.
~~~
Since I’m starting fresh with Dispatch reboot I’m also starting fresh on its tests. There’s a lot of interesting efforts going on in testing Scala and I thought, surely, I could find one that is built for the different versions of Scala I support. But that’s just not the case. I tried the usual suspects, as well as every upstart Scala testing framework I could find, and none of them are being dependably cross-published.
I was almost ready to switch to JUnit, which I have never actually used for anything—but hey, it works for Foursquare. Then I remembered to ask Josh Cough what to do. And he told me (as he told me a few years ago when I wasn’t ready to listen) to just use ScalaCheck.
Obviously, ScalaCheck is not cross-built and published for every version of Scala that I support but it has one big advantage: no dependencies. You can generally build it without a lot of drama. And that made me realize that the answer has been there since sbt 0.10: source dependencies.
In their local form, source dependencies are unarguably practical. I’ve never had a better workflow for developing both a library and client application at the same time: you save one file in the library and all dependent sources in both projects are recompiled.
The remote form of source dependencies is more ambitious, and also trickier. In the most common case you specify a git URL that references a specific commit and sbt will clone that project and build it locally. The tricky part is that although the project is okay to build in sbt, it’s in a strange new world when it comes to distribution.
You can’t publish the project’s binaries to a Maven repository. And if you’re building a WAR or a JAR or something else, it’s unlikely that the source dependency’s classes are going to end up in that archive without some gnashing of teeth your sbt build definition. About the only thing you can do in a straightforward way is have your project be used as a source dependency by something else, which is neat but unpopular.
With test dependencies, we just don’t have the problem. Test artifacts aren’t meant to be distributed, they’re meant to be run locally by the project contributors. After the compiled tests pass, you don’t worry about them or their dependencies. Your work is done.
So using test frameworks with a library is the perfect use case for source dependencies, and ScalaCheck with its uncomplicated build the perfect source dependency. I did have to fork the repo to make some superficial changes. Incompatibilities with Scala 2.8 were introduced at some point, so I rewound to the last version tag before that and back-ported the sbt 0.11 build definition, which took all of five minutes. I pushed my changes to a fork on github and that was it.
But the configuration for this on the client library side is not-obvious, and I went though a few ugly iterations of it before I came up with something fairly short and sweet. Here’s the crux of it:
lazy val ufcheck = Project(
"ufcheck", file("ufcheck")
).dependsOn(scalacheck % "test->compile")
lazy val scalacheck = RootProject(
uri("git://github.com/n8han/scalacheck.git#1.8cc")
)
(If it looks weird it’s because it’s doing something amazing that you
can’t do any other way.) ufcheck is some test code that I use in
other modules, but you can pretend it’s a library module that just
needs to use ScalaCheck. Its dependsOn clause sets a test
dependency on the compile classpath of ScalaCheck, which is
exactly what we need to do.
The scalacheck reference points to my fork and a tag “1.8cc”, which
is my way of saying it’s version 1.8 with a build that cross-compiles.
And that’s it. Dispatch reboot is testable for life. No matter what happens in the future, it can be tested against different versions of Scala without asking anybody to publish anything.
Since Scala 2.10 is right around the corner I can start thinking about dropping support for 2.8 and updating this source dependency to a newer tag of ScalaCheck, if I feel like it. Or I can support 2.8 through 2.10—whatever! My build is flexible, that’s the whole point.
If only the same trick worked on everything.
After some additional backporting, a new Release Candidate in the Scala 2.9.x series is now available for download: 2.9.2 RC2. This release includes many bugfixes, as well as backported documentation and scaladoc improvements from the community.
This RC2 release candidate is made available for testing purposes only and is not intended for production environments: a final 2.9.2 release will follow at the end of the RC cycle. Please help us with the testing of this candidate, and let us know of any issues that you may encounter.
We are very happy to announce a new release candidate for the next maintenance release of the Scala
IDE for Eclipse: Scala IDE 2.0.1 RC2 is available now!
The only change with respect to 2.0.1 RC1 is the bundled Scala version, which is now Scala 2.9.2-RC2.
Builder, Compiler and Editor improvements. And both Eclipse 3.6 (Helios) and Eclipse 3.7 (Indigo) are now officially supported! Read more...
What’s left seems like low-hanging fruit. I have heard nearly nothing about it, but I’ll be damned if twenty people aren’t sitting around working on it somewhere right now: There needs to be an object/node/graph database built explicitly on LINQ-like principles and in a way as to optimize for LINQ-based usage patterns. The data conforms to object patterns instead of its own designs. The kind of queries you send it informs a dynamic query analyzer, rebuilding and maintaining indexes for optimal access. You don’t have to worry, really, about primary keys, but more about references to other things.
In this post I want to show a few of the upcoming features in specs2-1.9 and also take a step back on how specs2 features and implementation unfolded since I started the project one year ago.
Good question, that seems to be very masochistic :-). Not only because of the sheer amount of features to re-implement but more importantly because of the difficulty to move users to a new version.
I explained in details the reasons why I thought the rewrite was necessary, how it would benefit users and how to migrate in a previous blog post. What I want to emphasize here is the compromise I decided to make at that time:
The main reason for this compromise was immutability. Forcing myself to immutability had opened the gates of robust and concurrent software but at the same time I had to cut back on the syntax I had proposed for the original specs1 project. For example it wasn't possible anymore to write:
// this example can only be "registered" if there are side-effects
"hello must have 5 letters" in {
"hello" must have size(5)
}
"world must have 5 letters" in {
"world" must have size(5)
}
Instead, I proposed to write:
// examples are "linked" together with the ^ operator
"hello must have 5 letters" ! e1 ^
"world must have 5 letters" ! e2
def e1 = "hello" must have size(5)
def e2 = "world" must have size(5)
The feed-back was immediate. Some developers who were sent a preview liked it but others told me: "NEVER I would use this horrible syntax". Ok, fair enough, I can't blame you, it's a bit ugly on the right.
I decided then that I would relax my constraints a little bit and add one, just one, var. It would only be used to accumulate examples when building the specification, to enable the good old specs1 style. This was also, at least partially, solving the migration problem since a full rewrite of the specifications was not necessary.
Not everything was as cool as in the original specs1 tough. In particular the super-easy "isolated" execution model was missing. Until...
... Until it struck me, just one month ago, that reintroducing this mode of execution was less than 10 lines of code!
Because I had chosen the functional paradigm of "executing a Specification" <=> "interpreting a data structure" it was really easy to change the interpretation to something declaring: "for each example, execute the code in a clone of the Specification so that all local variables are seen as fresh variables".
In terms of product management, it was a "magic" feature almost for free! To me, this is the illustration of a principle of Software: "if code is a liability, maximise your return on investment".
I'm sure you've already read something like: "features are an asset, code is a liability". But I haven't yet read the logical consequence of it: "Maximize the ROI: extract as many features as you can from your existing code". Indeed every time we write a piece of code, it's worth wondering:
That's exactly what happened with the "isolated" feature above. Here's another example of this principle in action.
A few months ago, I developed a feature to create an index page. On this index page I had to show the status of specifications which had been executed as part of the previous run. This meant that I had to store somewhere, on the file system, the results of each specification execution.
In terms of feature price, this is not a particularly cheap one. Everytime there is some IO interaction and some kind of serialization, the number of possible issues to consider is not so small. In a way that was really an "iceberg" feature: not a lot of functionality on the surface, but a lot of machinery under the water. So I wondered how I could improve my ROI on this. Hmm... since I'm writing status information to the disk there might be a way to reuse it!
Indeed, I can use this information to selectively re-run only the failed examples, or the skipped ones, or... And so on. From there, a new "feature space" opens, and the initial investment starts making sense.
It is also possible to maximize the ROI on existing features. A feature is an "asset". Perhaps, but it's not completely free either. You have to explain it, to promote it, to show when and how it interacts with the rest of the software. This is why maximizing the ROI of features makes sense as well.
That's exactly what happened with the brand-new "isolated" feature.
Year after year I'm looking at the specifications that people are writing with specs/specs2. Kind of my hallway usability test for open-source libraries... I usually see several "styles" of specifications and one style is pretty frequent:
"This is an example of building/getting/processing a datastructure" >> {
// do stuff
val data = processBigData
// check expectations
data must doThis
data must haveThat
data.parts must beLikeThis
// and so on...
}
In that style of specification, there is usually one action and lots of things to check. It is very unfortunate that most of the testing libraries out there will stop at the first failure. Because it really makes sense to collect all of them at once instead of having to execute the specification multiple times to get to all the issues.
Is there a way to "collect" all the failures in specs2-1.8.2? Not really. You can try use "or" with the expectations:
(data must doThis) or
(data must haveThat) or
(data.parts must beLikeThis)
And that will collect all the failures up to the first success, and then it will stop executing the rest. Besides, the "or" syntax with all the parenthesis is not so nice.
After a while I realized that the only way to make this work was to use yet another mutable variable to silently register each result. But then I'd be back to the old specs1 problem. What about concurrency? How can I prevent each concurrent example to step on another example results?
Well, that's easy, I have the "isolated" feature now! Each example can run in its own copy of the specification and the mutable variable will only collect the results from that example safely. The result is a feature that's easy to implement but also easy to use because it's just a matter of mixing a trait to the specification!
Can I go further with the same thinking? Why not?!
From the beginning of specs2, I liked the fact that the so-called "Acceptance specification" style allowed me to write a lot of text about what my system behavior and then annotate it with the actual code. The price to pay was all the symbols on the right of the screen which appeared utterly cryptic to some people (to say it nicely).
Then, last week, I realized that I could rely on something which exists in most code editors: code folding! In a classical JUnit TestCase, specs1 specification or specs2 mutable specification if you fold the code, you're left with only the text, forming a narrative for your system. If you see it like that, any specs2 mutable specification can be turned into an acceptance specification, just a few features are missing:
should/in blocks) and formatting fragments (for example to give an overview of the system, before going into the details)Not a lot to implement really. Most of the machinery is already provided by the org.specs2.Specification trait. This means that, for a very reasonable "price", you can now use "mutable" specifications in specs2 with a great deal of expressivity (nothing's perfect though, there are small issues due to semi-column inference for example, see here for variations around the "Stack" theme).
To me, it really feels that I've come full circle:
My only concern now is that newcomers might feel lost because the library is not really prescribing a specific style: "should I use a 'unit' style or an 'acceptance' style? And what are the differences between the 2 anyway?". I hope that they'll realize that this is actually an opportunity. An opportunity to try out different ways of communicating and then choosing the most efficient or pleasing.
by Eishay Smith (noreply@blogger.com) at March 22, 2012 04:07 PM
Adrian King
Alex Cruise
Arnold deVos
Christos KK Loverdos
Code Commit
Coderspiel
Daniel Sobral
Dave Briccetti
Dave Ray
David R. MacIver
Detering Dirk
Eishay Smith
Eric Torreborre
Erik Engbrecht
Erkki Lindpere
Francois Armand
Froth and Java
Functional Jobs
Gabriel C.
Graham Lea
Gregg Carrier
Heiko Seeberger
Hendy Irawan
Henrik Huttunen
Hossam Karim
Ikai Lan
Ismael Juma
Jack Cough
James Iry
Jesper Nordenberg
Jesper de Jong
Jesse Eichar
Jesse Eichar
Jim McBeath
Joakim Ohlrogge
Jonas Boner
Jorge Ortiz's Scala Tips
Josh Suereth
Kevin Albrecht
Kris Nuttycombe
L. Greg Meredith
Lalit Pant
Mads Hartmann Jensen
Mario Gleichmann
Martin Kneißl
Martin Odersky
Mathias
Matt Hellige
Michael Fogus
Michid's Weblog
Mirko Socker
Nikolaj Lindberg
Object Mentor
Paul Chiusano
Quoi qu'il en soit
Rafael de F. Ferreira
Razvan Cojocaru
Rich Dougherty
Richard Dallaway
Ricky Clarkson
Robey Pointer
Ruminations of a Programmer
Sam Newman
Scala Blogs
Sliding up the banister
Stefan Zeiger
Stephan Schmidt
Szymon Jachim
The Careful Programmer
The Grey Lensman's View
Tomás Lázaro
Tony Morris
Tony Sloane
Yuvi Masory
Zemian Deng
implicit.ly
scala-lang.org
Last updated:
May 18, 2012 10:01 AM
All times are UTC.
Powered by:
♀Planet Venus
