a soft sea

Braindump: The Twitter stack

Sun, 13 Jan 2013 19:47:00 -0500

For various reasons, including performance and cost, Twitter has poured significant engineering effort into breaking down the site backend into smaller JVM based services. As a nice side effect we’ve been able to open source several of the libraries and other useful tools that came out of this…

Coderspiel: Testing Scala Libraries

Mon, 02 Apr 2012 09:29:15 -0400

Coderspiel: Testing Scala Libraries:

coderspiel:

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…

Some ways to write function literals in Scala

Wed, 07 Mar 2012 00:19:57 -0500

coderspiel:

Just cuz iheardata asked and I can’t find a set of examples I like.

(i: Int) => i + 1

{ (i) => i + 1 }       : (Int => Int)
( (i) => i + 1 )       : (Int => Int)
{ i => i + 1 }         : (Int => Int)
( i => i + 1 )         : (Int => Int)
{ _ + 1 }              : (Int => Int)
( _ + 1 )              : (Int => Int)

(_: Int) + 1

giter8 0.3.2 - implicit.ly

Tue, 27 Dec 2011 15:08:13 -0500

giter8 0.3.2 - implicit.ly:

coderspiel:

Giter8 templates can now use ls to resolve the latest published version of a library.

There is some serious Scala web API ecosystem Zen going on here. Check it out. Oh and it uses parser combinators for the ls(…) business, so it’s l337.

I think we can manage

Tue, 13 Dec 2011 01:24:00 -0500

tl’dr: sbt Managed dependencies using git submodules on heroku. It can be done.

A post about source compatibility recently stirred up some commotion in the Scala community.

I too have felt some of the compatibility pain, but even though I have only been dancing the Odersky waltz for only a fraction of the time it takes to get on scala’s Dancing with the Stars, I believe I have seen hope. And I believe that source is the answer.

The `source` of the problem

In recent times, the common tech wisdom says that after 6-7 years, you are pretty much old news. The unfortunate news I have for you is that I think this is actually the time it takes to mature into something both dependable and beautiful. Younger, possibly cuter, programming languages will eventually learn that they will need to evolve and mature too, assuming they stick around for that long.

Evolution is in Scala’s blood. Some languages resist evolution in order to honor dead ancestors by carrying around spirits of the past. I don’t see Scala as a language that attends that same summer camp. As such, during its youth, Scala traded dead weight for a better design. The compromise was backwards binary compatibility. This obviously will cause issues with dependencies, hence the great debacle.

Simple, the way nature intended it

It wasn’t long before Sbt hit the Scala scene lookin’ all hipster-like from the frames of xml-configured eye glasses and roaming ants. Sbt gave us a number of things, one of which was the ability to build Scala software using Scala source code. The issues with source compatibility were known at that time too. Sbt’s the author couldn’t have made is simpler for library authors to wrangle the the issue of publishing binaries for their libraries across any combination of Scala versions you can think of.

The hat trick was to take something like

 publish

and turn into something like

+ publish

To this day, it baffles me that some library authors haven’t caught on to this and even complain about it. I can’t see it getting any more simple that adding a single operator. Although I can see some talking issue with it being an operator. ( Just kidding guys :) )

But there was something even more beautiful that came out of those early versions of Sbt: source dependencies, dependencies that could be managed for you and be compiled right along side your code using the same version of Scala.

Fast forward, Let’s `git` to the point

The latest versions of Sbt also support source dependencies, but through a much more powerful tool, git.

In addition to resolving dependencies through ivy/maven identifiers, Sbt now provides a simple way for declaring managed source dependencies through git uris, another under-rated, and probably under used featured among library authors.

 lazy val mahSourceDep = uri("git://github.com/the/awesome.git")

Here’s the nice thing about git. It’s all about the versions!

lazy val mahSourceDep = uri("git://github.com/the/awesome.git#mahbranch")

lazy val mahSourceDep2 = uri("git://github.com/the/awesome2.git#mahtag")

lazy val mahSourceDep3 = uri("git://github.com/the/awesome3.git#mahsha")

While I agree mvn published-versions of libraries work well for binary dependencies, I can’t really see authors publishing a binary for every bug fix/commit. But you know where I can see them publishing them to often? git.

As such, for agile development and a community-driven workflow, the more I look to a system mostly defined in terms of xml and reversed domain names that don’t really mean anything anymore, the more it feels a bit, antiquated? Don’t quote me on that! I know you’ve been doing this since before I was in short pants. I’m just sayin’.

Heroku me loco

That’s not the only way to play the source fiddle. Once you have your highly-scalable, fault- tolerant web 4.8 online pet store ready to go, the next step is to get it hosted.

My recent love affair with hosting has been with Heroku. Why is Heroku different than other hosting providers? Heroku gets developers. Heroku gets developer workflows. Heroku gets git.

How do you deploy am app on Heroku?

git push heroku master

KA-POW!

Don’t worry Scala coders, Heroku speaks many dialects of sbt.version.

So now that I’ve got you all PUMPED about source dependencies and Heroku. I’m going to tell you a stort fail story. And then I’m going to tell you another story. About not failing. About source. And git. And not failing.

I recently refitted a GAE armored app with the scantily garb of nothingness Heroku requires and tripped on a bump in the cloud.

The way Sbt git source dependencies work is that it clones them into a staging area, outside of your project, before compilation. So what’s the problem with that? When you push to Heroku you are actually triggering the compilation of something called a slug. Heroku is smart enough to know how to detect your flavor of slug (language), but there is one thing you should be aware of.

There ain’t no writing to disk in a cloud an their ain’t no special treatment for staging a clone out side of your slugs play pen!

insert crazy angry face here

Well that’s just great. All this show and dance and no payout. Well, that’s not the end of the story my friends.

If there is once thing for certain with Sbt’s new awesome design, it’s that you’ve got options™.

A good friend of mine pointed out that you can actually use git as unintended with Sbt for profit.

Here are the secret ingredients.

1) Git will, by default, allow you to create submodules in any subdirectory of a repo.

2) Sbt will, by default, resolve “unmanaged dependencies” under your projects ‘lib’ directory.

3) Heroku will allow you enable submodules

So if you declare a submodule for your awesome dependency

 $ git submodule add awesome git://github.com/the/awesome.git#mahbranch lib/awesome
 $ git submodule init
 $ git submodule update

And tell sbt to depend on it

  lazy val mahAwesomeDep = file("lib/awesome")

and enable gitsubmodules on Heroku

  $ heroku labs:enable git_submodules

You may just get your wings after all

  git push heroku master

Don’t believe me? I’m doing it now.

411s, InputStreams and chunked content

Fri, 25 Nov 2011 14:38:08 -0500

tbje:

Working on our API the other day I came over an incompatibility issue with our front end server and the Dispatch http library. Some web servers does not accept chunked data input by default (nginx for instance) and will reply with a 411 error code.

If you post a file using an InputStream with Dispatch, it will send the data in chunks which is great unless an incompatible server is receiving the data.

Read More

sticking ? where it doesn't belong

Sun, 20 Feb 2011 02:55:00 -0500

One fondness I have in common with Ruby, Clojure, and even Coffeescript is a syntactic idiom of ending the names of functions and methods that return a false value with a ?.

The idea is to immediately convey the intent of the function by means of an expectation you’ve developed reading natural language. When you read something that ends in a ?, you intuitively assume, without thinking, that sentence will result in a yes or no answer. Agree?

In Java land, the idiom is to prepend methods that return a boolean value with is. An example would be isJavaLike(). The idiomatic way in the languages listed above for expressing this would be javaLike?. I prefer predicate methods that end with ? because they read nicer and follow consistent rules. Let’s say you have a method is() in Java that returns a boolean value. If you wanted to be consistent you’d say isIs(). Chances are, you would break consistency and just stick with is() because isIs() just sounds silly. In the languages mentioned above, is? is idiomatically consistent and still readable.

flex time

In my spare time I like to whittle projects made of Scala. Scala is a super-flexible language that allows you to create fluent DSL’s by combining first class functions with a relatively open list of characters that you are free to use for method names.

The only complaint I have is that, while the method definition

def __^|(i: Int) = i % 2 == 0

is syntactically valid

def even?(i: Int) = i % 2 == 0

is not!

If you paste that in a Scala REPL you are likely to get this error

<console>:1: error: '=' expected but identifier found.
       def even?(i: Int) = i % 2 == 0
               ^

Method names in Scala can not end with ?.

How displeasing. :/

Some Scala libraries like Lift have an awkward response to this grammar constraint. In Lift, it is idiomatic to end method names that return boolean values with _?. The even method above would be defined as even_? in Lift. This feels very awkward to me because there is a disconnect in consistency with the mixing of camelCase method names with snake_casing. Something about fooBarBaz_? just doesn’t feel right to me. Does it feelRight_toYou_?.

I should mention at this point that if you read the Variable Declarations and Deﬁnitions section of the language spec you will see the use of def x_= (y: T ): Unit, suggesting the using of _ as suffix for mutating members. This has always felt awkward to me as well. In these cases, I prefer returning a new copy of type Foo given the method def x(y: T): Foo which retains the method name, unchanged, verses appending a _ and mutating the instance.

But I digress…

Well, Scala is a flexible language so of course there are ways to work around this.

And I’m not talking about something like

 def `even?`(n: Int) = n % 2 == 0

In languages like Ruby, you can monkey patch a class. In Scala, you use types to implicitly decorate values.

My first thought was to do something like

implicit def questionable[T](b: Boolean) = new { def ? = b }

This will enable you decorate any expression that returns a boolean value with a ?.

So, you could say something like

if(true?) ...

But that flavoring doesn’t necessarily have the same sweetness to it with methods that take arguments.

if(even(3)?) ...

The ? must come after then expression.

Well then, how about

 implicit def questionablefun[T](b: T => Boolean) = new { def ? = b }

 def pred[T](f: T => Boolean)(t: T) = f(t)

Let’s hear if for first class functions and currying!

Given the tools above, we can now assign a curried function that returns a boolean to a value and end that with a ? prior to applying the second argument.

val even = pred((i: Int) => i % 2 == 0)_

if(even?(2)) ...

Ha. Take that silly syntax grammar rules!

Now, of course I would not recommend doing something like all that in a production environment, but it does put a smile on my face just knowing that I can. For the time being I will be content with neither is, ?, nor _? and just stick unadorned intention revealing method names with context

if(allElseFails(Seq(4, 8, 15, 16, 23, 42))) ...

Works for me.

mime seating arrangments on airplanes

Tue, 14 Dec 2010 22:46:00 -0500

Recently I’ve been getting more into the idea of cloud hosting for tiny apps. Google App Engine is a perfect fitting glass shoe for applications written in java and other jvm languages of the future. The the world of scala we have sbt, and in the world of sbt we have plugins and in a world of repeatable tasks, we even have templates. Anyway… Even with a world of such luxury we sometimes can’t afford to make certain types of assumptions.

Living in a western world, it easy for most to people to live complacently with applications configured to use western only character sets. In the case of of applications serving string data outside those character encodings we have a few options. One of the most common encodings for multi-byte string content is utf-8. To enforce it, we were given weapons. Get into the habit of always putting the following line at the top of the head section of any rendered html.

<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

Recently I learned a new trick. As much as I despise java’s apparent fetish with xml configuration there is actually a handy block of code you can add to your web.xml config that should provide a suggestive hint to your servlet container to use a particular mime type for a given file extension when serving static content. It’s called mime-mapping. I think the original idea was to be able to provide a custom mime mapping for custom file extensions but you can also use it to override the default mime time for the most common string based file types of the interwebs. In doing so, you can have the oppurtunity encode the character encoding within the mime type as follows.

To reiterate.

before

> curl -I http://northeastscala.appspot.com
HTTP/1.1 200 OK
ETag: "zqO8fA"
Date: Wed, 15 Dec 2010 03:42:39 GMT
Expires: Wed, 15 Dec 2010 03:52:39 GMT
Cache-Control: public, max-age=600
Content-Type: text/html
Server: Google Frontend
Transfer-Encoding: chunked

after

> curl -I http://northeastscala.appspot.com
HTTP/1.1 200 OK
ETag: "MJtj8Q"
Date: Wed, 15 Dec 2010 03:43:23 GMT
Expires: Wed, 15 Dec 2010 03:53:23 GMT
Cache-Control: public, max-age=600
Content-Type: text/html; charset=utf-8
Server: Google Frontend
Transfer-Encoding: chunked

Don’t expect utf-8 content to be served when your app first jumps off the app engine plane. I did and it was kind of embarassing. It’s best to be safe and strap yourself in next to a mime you can trust.

magic match sticks and burnt fingers

Sat, 04 Dec 2010 21:37:00 -0500

First class pattern matching support is one of the many ways Scala stole my heart. I now use pattern matching as a superior refactoring and design tool in place of most every use case where I would historically insert another stray branch into a nest of ifs or query methods. Scala’s match keyword does what most languages switch or case keywords should do. Some may argue there’s too much magic behind it but once you understand that happens behind the curtains with unapply, most of that unfounded distrust goes away. For me, it’s just just the right amount of magic for me enjoy sticking my hand in the magician’s hat without the fear of uncertainty.

That doesn’t ways mean what my hand draws from the magicians hat is always what I expect.

Let’s look an extremely contrived example of using pattern matching.

def isRabbit(contents: String) =
  contents match {
    case "Buggs" => true
    case "Roger" => true
    case "Jessica" => false
    case _ => false 
 }

I’ve seen this trick enough to know that when I put my hand in, I have a pretty good idea of what I’ll get out depending on it’s contents. When see the magician stuff Buggs bunny into his hat before the show, I know I will pull out a rabbit. When I see the magician stuff Jessica Rabbit into his hat before the show, I know I will not being pulling out a rabbit. We’ve all been to that show before.

Now. We are good at extracting the hardcoded string values of our applications are’t we? Let’s extract thems that be causin all the code smell.

val buggs = "Buggs"
val roger = "Roger"
val jess = "Jessica"

def isRabbit(contents: String) =
  contents match {
    case buggs => true
    case roger => true
    case jess => false
    case _ => false 
 }

Can you guess what the contents of the hat will reveal when the magician puts “Roger” into the hat before the show? You sure? Okay. Now paste the code above into your nearest scala repl.

Ouch! Looks like you just got burnt. What’s with all this error: unreachable code business? Scala is supposed to prevent me from having buggs in my program, isn’t it?

Unbeknownst to me until recently is a little bit of knowledge that I hope to bestow upon the likes of you. So quiet the television and come sit close to the fire. Scala’s pattern matching engine will not treat lowercase variable names the same as will their value in match clauses. Don’t assume you can just use variables in the values’ stead without getting burnt. But, there is hope for sorry souls.

Scala has a convention for naming contants and so does English for its proper nouns: the first letter should be upper-cased.

Let’s revisit this ridiculous example so I can get to the point. Let’s rename those proper nouns using upper case identifiers.

val Buggs = "Buggs"
val Roger = "Roger"
val Jess = "Jessica"

def isRabbit(contents: String) =
  contents match {
    case Buggs => true
    case Roger => true
    case Jess => false
    case _ => false 
 }

Ah, ha! It totally works now. Why? Because scala treats pattern match case arguments that are identifiers as extractors and by convention an identifier starting with an uppercase letter is assumed to be a constant identifier. A constant can statically be compiled in bytecode because it will not change. A lowercase identifier by convention is not, and therefore is a lesser citizen and can be assumed to vary at runtime and cannot be statically compiled as a pattern match clause. So why do inline, hard coded strings work then? Duh. Strings are immutable and can not change so they can be statically compiled with the pattern match clause. With this information in hand, we should hopefully see why the semi-compiled version using lower case variable names errors out. The remaining case statements would never be reached and Scala thankfully lets us know this at compile time. One of the benefits you are afforded in a statically compiled language. At least this is my hypothesis :)

Before this magic show ends, I’d like to point out a lesser know feature of Scala’s syntax. Enter: the backtick! In some rare cases where you can just not stand to not use lower case variable names or when you get the itch to name something using a language keyword, you can wrap the identifier in a set of backticks. This will say to Scala: “Hey, I know this is wrong but give me a break. The magic business hasn’t been all that great lately”. Scala, being the nice language it is will reply: “Okay, I’ll let is one go for now”.

So if you absolutely wanted to use lower case identifiers in pattern match clauses, you can sneakily get away with the following.

def isRabbit(contents: String) =
  contents match {
    case `buggs` => true
    case `roger` => true
    case `jess` => false
    case _ => false 
 }

An surprisingly you can also get away with tomfoolery like this.

val `val` = "ue"
println(`val`)

the magician bows

I’d like to thank @boia01 and @jorgeortiz85 for some helpful insight on some frustration I had with an almost unrelated issue but with a totally related answer.

Enjoy the show!

Holy Blinking MAGENTA

Sun, 01 Aug 2010 20:24:00 -0400

a paraphrased back-in-my-day

Have you ever wondered how some command line programs add artistically horrid colors to textual output? Ever wonder why you might see an ls listing showing directories in yellow or soft-linked files in red on some machine terminals and not others. I love colors as much as anyone else does, so I’m curious too.

Well, back in the days before we had a style markup language for designers we had programmers design a style markup language for… programmers. Some OS’s may vary but basically the magic seeps from an environment variable called LSCOLORS and the ls command line flag --color or another environment variable called CLICOLOR.

Back in those arcane days we didn’t have any of these fancy pants style sheets so the best we could come up with was the following approach.

First, define a set of finite codes that indicate which ANSI colors are available.

Then define an indexing for types of file listings based foreground+background pairings

The result of which being something like

export LSCOLORS=dxfxcxdxbxegedabagacad

Pretty obvious and easy to read huh?

a Scala crayon box

The other day I was playing around with Scala’s REPL and came across something new. By now I should hope we all know about Scala’s Predef object. Where else do you think all of those implicit conversions are coming from? Ohio? Referenced inside Predef is one neat little class that’s easy to look right past: Console. Console provides us with some wildly fun library methods like println and readLine. What fun right?

So what’s Console got to do with color? Everything.

One of the newer features of Scala’s REPL is method tab completion. I see some irb users in the back yawning so I’ll get to my point. One of the useful side effects of having tab completion is api discovery. Guess what I get if I crack open a Scala REPL and type

scala> Console.<tab>

BLACK          BLACK_B        BLINK          BLUE           BLUE_B         BOLD           CYAN
CYAN_B         GREEN          GREEN_B        INVISIBLE      MAGENTA        MAGENTA_B      RED
RED_B          RESET          REVERSED       UNDERLINED     WHITE          WHITE_B        YELLOW
YELLOW_B       asInstanceOf   err            flush          in             isInstanceOf   out
print          printf         println        readBoolean    readByte       readChar       readDouble
readFloat      readInt        readLine       readLong       readShort      readf          readf1
readf2         readf3         setErr         setIn          setOut         toString       withErr
withIn         withOut

Hrm… What’s this?

What are all these values named after ANSI colors doing in Console’s pantry?

What you will find is that Console has provided functions values for colorizing… your console’s output. What can we do with this? Colorize your CLI’s interface and make it all pretty like. The convention is Console.{COLOR} for setting foreground colors and Console.{COLOR}_B for setting background colors. Pretty sweet.

So in your REPL you can type

scala> Console.MAGENTA_B

Which will turn your terminals background to a nice shade of magenta.

Then add a tasteful green foreground with

scala> Console.GREEN

You should see some thing like

scala> “colors” :: “are” :: “awesome” :: Nil mkString(” “)

But wait there’s more. There’s BLINK! Your remember <blink></blink> don’t you?

So does Scala

scala> Console.BLINK

and behold

scala> “colors” :: “are” :: “awesome” :: Nil mkString(” “)

Don’t worry. You can always revert these changes to console output with Console.RESET.

Optionally, if you are feeling like a coding ninja I’d recommend Console.INVISIBLE

These are the things I live for.

a well formed cupcake

Mon, 19 Jul 2010 01:22:39 -0400

Here’s a simple little sprinkle for anyone wondering how to serve xml with self-closing tags in Scala.

The basic cooking ingredients in Scala’s xml kitchen will output closing tags, even when the recipe does not call for them.

val selfClosingCupcake = <cupcake />

Will always unsuspectingly return

<cupcake></cupcake>

When your cupcakes are html tags, sometimes the extra closing tag is not valid.

The output

<link rel="stylesheet" href="cupcakes.css"></link>

may be tasty, but is less than valid.

The solution is simple. Sprinkle your xml with xml.Xhtml.

val selfClosingCupcake = xml.Xhtml.toXhtml(<cupcake/>)

This yields pretty much what you’d expect.

<cupcake/>

sweet teething

Beware of a few caveats.

Always put this call to toXhtml at the end of your processing pipeline as this returns a String rather than one of the handful of native xml types Scala provides.

If you were wondering, yes you can always step back into that native kitchen with XML.loadString

xml.XML.loadString(xml.Xhtml.toXhtml(<cupcake />))

Also of note.

Be aware of the xml api changes between Scala 2.7.* and 2.8.*

Scala 2.7.7.final requires you to pass in two extra args.

def toXhtml(n: Node, stripComment: Boolean, convertAmp: Boolean): String = {
  val sb = new StringBuilder()
  toXhtml(n, TopScope, sb, stripComment, convertAmp)
  sb.toString()
}

While Scala 2.8 blessed the community with default args.

def toXhtml(node: Node): String = sbToString(toXhtml(x = node, sb = _))

please yield to passing monads

Sun, 11 Jul 2010 02:41:00 -0400

One of the most common functional programming topics tossed about in the Scala community are monads. Even if you may not know what they are, chances are, you probably use them all the time.

Though there are already some decent postings on monads in Scala, I’d like to take a time out and describe how they are used in the Scala you probably use every day.

Raise your hand if you’ve ever pattern matched on a value that returned Some or None in Scala. Now raise your hand if you’ve ever used a Map in scala. If you raised your hand at least once you already use the most common monad in scala, Option. So what does it mean to be a monad?

That’s Monad not Nomad

Monads enable you to encapsulate the application of a function to a typed set of arguments. In other words, function bindings. Scala provides a few simple idiomatic tools do so: map and flatMap. You will find these implemented on many of the built in collections classes.

So why would you want to encapsulate a function’s application? Functions can have side effects. Functions can result in exceptional or illegal states of an application. Sometimes these exceptional states are declarative. With the support for higher-order functions in Scala, you can describe what something does without stating how. Thats where monads come in.

Back to our story. So. Option. What’s it to you? If you take a look at its source you see Option implements map and flatMap as

def map[B](f: A => B): Option[B] = 
  if (isEmpty) None else Some(f(this.get))

def flatMap[B](f: A => Option[B]): Option[B] = 
  if (isEmpty) None else f(this.get)

These are binding functions. If you are used to coming from most languages, you are probably used to writing defensive code in the form.

if(obj != null) {
   obj.play();
}

This is actually just a poor man’s abstraction for handling an erroneous state that is admittedly a a billion dollar mistake. Option is a monad that shields you from this messy situation and provides a higher level of abstraction, you either have Some value or None.

Are You or Are You Not Comprehending

That’s cool and all but how is that actually useful? Comprehensions my friend Watson.

Scala provides us with a pretty neat little control structure that might seem a bit strange in a world of inferior loops. I say inferior because most modern languages have control structures that allow you to just loop over collections of values without returning anything resulting in implicit side effects. I will call these for loops. In functional programming, it is idiomatic that everything returns a value. In Scala, I will call a for loop’s analogy a for comprehension. I say comprehension because Scala is doing more that just naively looping over values. It is comprehending their arguments and applying functions by monadic means. This has much in common with Haskell’s do notation.

A refresher on for comprehensions.

In Scala, there are two usages of the for control structure.

First up is a for that returns Unit

for(i <- List(1, 2, 3)) { println(i) }

This, in its most basic form, looks outwardly like a loop control structure in other languages. In someways it is and in some ways it is not.

The main difference here is that the contents of for’s first argument can actually be stackable and contain logic.

for(i <- List(1, 2, 3); if(i > 1);
    j <- List(4, 5, 6)) { println(i * j) }

The second form is a for that returns a generated value.

for(i <- List(1, 2, 3)) yield { i * 2 }

This yields the value of List(2, 4, 6).

The generative form is the preferred form as you are returning the value of computation rather than performing a side effect like printing to standard output. This form also lends itself toward better testability and referential transparency.

This Ain’t your Mom’s Dad

So what’s do comprehensions have to do with Option?

There is some sleight of hand going on behind the scenes in a for comprehension.

Firstly, when you blur your eyes a bit you can see that for has the same appearance as a curried function.

foo( ... )( ... )

In Scala, parens are interchangeable with curly braces which can make a curried function look or feel more like a control structure.

for( ... ) { ... }

And if you really wanted

for { ... } ( ... )

But enough with emoticons.

You can actually apply any value as the first argument of a for comprehension given the following constraints.

For the Unit flavor of for comprehensions, your object must implement

def foreach[U](f: A => U): Unit

For the generative flavor, you must implement

def map[B](f: A => B): M[B]
def flatMap[B](f: A => M[B]): M[B]

Where M is the type of Monad

Remember the currying I mentioned above? You can think the second half of the curry as the function f in map and foreach. The function that gets passed to flapMap is the result of the map operation at the inner most <-. This is the magic sauce that makes Scala’s for comprehensions chainable.

In Scala 2.8, you will also probably want to implement

def withFilter(f: A => Boolean)

WithFilter is used to support conditional logic within for loops.

Again, what’s all of this have to do with Options? Keep your bonnet on!

Guess what, Option just happens to implement all of these.

for(i <- Option(1)) { println(i) }

Prints 1

for(i <- Option(1); if(i > 1);
    j <- Option(4)) { println(i * j) }

Prints nothing (because the value of i is not greater than 1.

for(i <- Option(1)) yield { i * 2 }

yields Some(2)

And… Since these monadic for comprehending Options return Options you can append a default value at the end of a computation

(for(i <- Option(1); if(i>1)) yield { i * 2 }).orElse(Some(4))

yields Some(4)

Mmmm. Ok.

For Tickling Monads

Let’s take a closer look by implementing a for comprehending monad called Focomo that prints some output to show what in the tarnation for comprensions are doing with values. Sorry kids, for simplicity sake, Focomo will not do anything interesting based on what the the actual value is. We just want to see where for comprehensions like to tickle their arguments.

/** A for comprehension ready Monad */
case class Focomo[A](value: A) {
  self =>
  /** satisfies monadic binding of a function f that returns B */
  def map[B](f: A => B): Focomo[B] = { 
    println("map!"); 
    Focomo(f(value)) 
  }
  /** satisfies monadic binding of a function f that returns Focomo[B] */
  def flatMap[B](f: A => Focomo[B]): Focomo[B] = { 
    println("flatMap!"); 
    f(value) 
  }
  /** expect this to be called in a `Unit` for comprehension */
  def foreach[U](f: A => U): Unit = { 
    println("foreach!"); 
    f(value) 
  }
  /** for comprehension's `if` statements trigger this. 
   *  In a more useful monad, the result of the application 
   *  of a value to function f would determine the a special subclass
   *  of the monad or other either-or behavior.
   */
  def filter(f: A => Boolean): Focomo[A] = { 
    println("filter!"); 
    this
  }
  /** provides a delegate handler for calls to #withFilter */
  class WithFilter(p: A => Boolean) {
    println("with filter!")
    def map[B](f: A => B): Focomo[B] = self.filter(p).map(f)
    def flatMap[B](f: A => Focomo[B]): Focomo[B] = self.filter(p).flatMap(f)
    def foreach[U](f: A => U): Unit = self.filter(p).foreach(f)
    def withFilter(q: A => Boolean): WithFilter =
      new WithFilter(x => p(x) && q(x))
  }
  /** called with conditional statement in for comprehension */
  def withFilter(p: A => Boolean): WithFilter = new WithFilter(p)
}

Let’s play.

for { i <- Focomo(1) } { i }

Prints

foreach!


for { i <- Focomo(1); if(i < 2) } { i }

Prints

with filter!
filter!
foreach!

for { i <- Focomo(2) } yield { i  }

Prints

map!

And returns

Focomo(2)

for { i <- Focomo(2); j <- Focomo(3) } yield { i * j }

Prints

flatMap!
map!

And returns

Focomo(6)

And lastly,

for { i <- Focomo(2); if(i<4); j <- Focomo(3) } yield { i * j }

Prints

with filter!
filter!
flatMap!
map!

And Returns

Focomo(6)

So what did we get out of all of this? Well, not much from our little Focomo :). What I hope you did learn was the basic building blocks of how you can take advantage of the monadic hooks Scala provides in for comprehensions and how monads themselves are useful for encapsulating function bindings and managing common side effects.

referential transparencies

Sat, 15 May 2010 12:36:00 -0400

Oftentimes when shifting back and forth between languages it’s easy to fudge syntactic nuances out of habit. Sometimes when you fudge you learn something new. Today I fudged some Java in my Scala.

What would you guess the return type of the following method to be?

def guess(what: String) {
   "%s? really?" format what
}

One who is used to Scala by now knows there’s no need to explicitly declare a return type, let alone use the return keyword at the end of a method thanks to this fancy pants thing called type inference.

So what’s the fuss with this simple example? It obviously returns a String, duh. WRONG.

Scala is part functional and part of that functional nature includes referential transparency.

Functional Projectors

Referential what? Databases? Overhead projectors?

So what does referential transparency mean? It’s simple.

Say you have a value v and are assigning it the result of function f which takes the argument a:

val v = f(a)

Function f is said to be referentially transparent, if you can replace all occurrences f with the the result of applying the same value a to f and always end up with the same result.

Huh?

In functional programming, the idea is that functions should be side effect free, so it’s okay to replace f(a) with just the resulting value of f(a) because your program will not modify state that would adversely affect the result of f(a).

Mixed Flavors

So what’s this have to do with fudge and Java?

As Scala has inherited some of Java’s syntax, Javaisms can creep into your Scalaisms.

Case in point:

def guess(what: String) {
   "%s? really?" format what
}

The Scala return type of this method is actually Unit. The correct way to declare this method in Scala is:

def guess(what: String) = {
   "%s? really?" format what
}

or even better (more minimal)

def guess(what: String) = "%s? really?" format what

So what changed? You assign the name of the function to the it’s functional body. If you’ve been paying attention, you’ll pick up on the fact that this is the functional style. If you are being referentially transparent the about your design you can say

val stringGuessResult = "String? really?"
val guessResult = guess("String")
stringGuessResult == guessResult

where the resulting value is always the same.

In the same manner declaration of function names follow suit.

fnNameWithValue = value
fnNameWithFunctionBody = functionBody
fnNameWithValue == fnNameWithFunctionBody

Without the assignment operator, the { ... } brackets from the previous example merely serve as a means of scoping local variables. The environment surrounding the brackets can not know what kind of scheme the local variables are plotting.

Border Crossing

This key-value concept of assigning function names to function bodies is also common in other languages. Let’s take the same example in Javascript.

As Javascript also inherited some of its syntax from C, you can declare methods in a C-like fashion

function guess(what) {
  what + "? really?"
}

You can also write this in the functional style

var guess = function(what) {
  what + "? really?"
}

Does this look familiar?

var someModule = (function(){
   return {
     guess: function(what) {
        what + "? really?"
     },
     tell: function(story) {
        "my story is "+ story
     }
   };
})();

Or even

$.ajax({ 
   url: "...", 
   context: document.body, 
   success: function() {
     alert("All done!");
   }
});

Both are use cases for using the functional style of assigning a function body to a name.

Back to Our Story

Just for fun let’s say you actually did assign and explicit return type for the previous example with out assigning the the method body.

def guess(what: String): String {
   "%s? really?" format what
}

You actually end up with a compile error.

illegal start of declaration (possible cause: missing `=' in front of current method body)

Ops! You’re Java’s showing.

Overlapping Transparencies

When you think about it, referentially transparency seems the like same idea behind vals. You are assigning some resulting value to a name which cannot change unless explicitly overridden in a sub type. For a program to be side effect free, one might say that when part of a program accesses a val, the val should always return the same referentially transparent result.

a transitional suitcase for source

Sun, 18 Apr 2010 00:10:00 -0400

With the recent announcement of Scala 2.8.0 RC1, I finally decided it was time to start transitioning some of my projects. For more motivation, as 2.8 becomes main stream I’m sure some issues are bound to pop up.

does a cat’s pur make a sound if no one is around to hear it

I picked a smaller project to start out with, because low hanging fruit usually tastes better when transitioning to the next major release of a language.

Sbt’s cross building feature makes it stupid simple to add another supported Scala version to your project by cracking open your project/build.properties file and appending a new one.

build.scala.versions=2.7.3 2.7.4 2.7.5 2.7.6 2.7.7 2.8.0.Beta1

If that wasn’t easy enough, try compiling your project across all noted versions by executing the compile action with a +.

+compile

The + applies action against all versions noted under build.scala.versions.

A wave of sbt’s magic wand and… FAIL!

[info] Building project meow 0.1.0 against Scala 2.8.0.Beta1
[info]    using MeowProject with sbt 0.7.1 and Scala 2.7.7
[info] 
[info] == compile ==
[info]   Source analysis: 1 new/modified, 0 indirectly invalidated, 0 removed.
[info] Compiling main sources...
[error] [snip]/meow/src/main/scala/meow/Growl.scala:23: missing arguments for method getLines in class Source;
[error] follow this method with `_' if you want to treat it as a partially applied function
[error] Error occured in an application involving default arguments.
[error] Error occured in an application involving default arguments.
[error]   val bin = Source.fromInputStream(which getInputStream).getLines.mkString("").trim
[error]                                                          ^
[error] one error found
[info] == compile ==
[error] Error running compile: Compilation failed

What’s this? Source#getLines and default arguments?

I hopped over the the scala doc online for this method and things looked fine according to the documentation.

On an aside, it should be noted that Scala’s methods can have zero arguments implicitly by declaring a method’s signature to be def foo with the uniform access principle in mind or explicitly by declaring a method’s signature to be def foo() with a set of empty parentheses. In general, those without parentheses are assumed to have no side effects and those with parentheses are assumed to have some side effects. When you define a method without parentheses you can not invoke it with parentheses.

So what happened here?

I cracked open the scala 2.8.0 beta library source jar to get the definition of its Source#getLines

/** returns an iterator who returns lines (NOT including newline character(s)).
 *  If no separator is given, the platform-specific value "line.separator" is used.
 *  a line ends in \r, \n, or \r\n.
 */
def getLines(separator: String = compat.Platform.EOL): Iterator[String] =
  new LineIterator(separator)

Hrm, looks like we’ve got a bit of backwards compatibility problem here. Source#getLines will compile in anything < 2.8 but will not in anything > 2.8 and Source#getLines() will compile in anything > 2.8 but won’t in anything < 2.8.

a transitioning suitcase

After some thinking, I decided it might be best to wrap Source in some new clothes that would insulate me from the cold winds of this compatibility issue until I can come up with a better solution. I came up with a Transitioning module that adds a lines method to Source and which I can add other implicit wrappers to if I find other issues.

object Transitioning {
  import scala.io.Source
  class TransitionalSource(src: Source) {
    class LineIterator(iter: BufferedIterator[Char], separator: String) extends Iterator[String] {
      require(separator.length < 3, "Line separator may be 1 or 2 characters only.")

      private[this] val isNewline: Char => Boolean =
        separator.length match {
          case 1 => _ == separator(0)
          case 2 => {
            _ == separator(0) && iter.hasNext && {
              val res = iter.head == separator(1) // peek ahead
              if (res) { iter.next } // incr iter
              res
            }
          }
        }

      private[this] val builder = new StringBuilder

      private def buildingLine() = iter.next match {
        case nl if(isNewline(nl)) => false
        case ch =>  { 
          builder append ch
          true
        }
      }

      def hasNext = iter.hasNext
      def next = {
        builder.clear
        while (hasNext && buildingLine()) {}
        builder.toString
      }
    }
    def lines = new LineIterator(src.buffered, compat.Platform.EOL)
  }
  implicit def src2transitionalSrc(src: Source) = new TransitionalSource(src)
}

To test this, let’s say we have a file called test.txt that contains the contents:

hi
there
file
of lines

As an example let’s try the following.

import Transitioning 
import scala.io.Source
import java.io.FileInputStream

Source.fromInputStream(new FileInputStream("test.txt")) lines // List(hi, there, file, of lines)

Sweet! It works.

As a reconfirmation, I added this module to my project, swapped Source#getLines with Source#lines in my own source code, re-waved sbt’s magic +compile wand and… WIN!

[info] Building project meow 0.1.0 against Scala 2.8.0.Beta1
[info]    using MeowProject with sbt 0.7.1 and Scala 2.7.7
[info] 
[info] == compile ==
[info]   Source analysis: 2 new/modified, 0 indirectly invalidated, 0 removed.
[info] Compiling main sources...
[info] Compilation successful.
[info]   Post-analysis: 24 classes.
[info] == compile ==
[success] Successful.

there are only some ways to mix a cat

Sun, 04 Apr 2010 21:13:00 -0400

A newish mixology

There’s something to be said for the ability of a language allow the design types of objects through composition rather than traditional class inheritance. It awesome! Aristotle was correct in that things can be classified according to thier common characteristics. In software, it seems kind of overly ambitious to think that this should be the same basis of all object design. Most of my own charateristics did not come from my parents. I aquired them from my own schooling and experiences and interactions with others.

Designing software in terms of composition, mixins, also promotes code reuse, because you are isolating areas of concern which can be reused across multiple class hierarchies. When you narrow your areas of concern, your design of modules can be very specialized in a decoupled manner, not really carring about who thier daddy is.

Think about this the next time you add new behavior to your classes: Is your class an instance of iterable or is iterable a trait that can be observed in multiple types? Is your class an instance of a behavior or is the behavior a trait that can be observered in multiple types. It’s all a matter of perspective. Lately I’ve been siding on the former side of the previous two statements.

Mix ins and outs of Scala and Ruby

In Scala, mixin composition comes in the form of abstractions called traits. Languages like Ruby also provide a means of designing software through composition via Modules.

In Ruby you express mixins as:

module A
  def foo
    puts "I was born in module A"
  end
end
module B
  def bar
    puts "I was born in module B"
  end
end
class C
  include A
  include B
end

And in Scala:

trait A {
  def foo = "I was born in trait A"
}
trait B {
  def bar = "I was born in trait B"
}
class C extends A with B

Sometimes it’s you want to mix in behavior for only one instance of a type. In Scala you can do this easly in the form:

class D
val specialD = new D() with A with B

My first attempt do this in Ruby failed. At first I thought I could do something like:

class D
end
special_d = D.new.instance_eval {
  [A, B].each { |mod| self.class.send :include, mod }
} #=> [A, B]

but the D.new.instance_val actually returns an array of A and B so you couldn’t immediately call a module method on the resulting value.

This actually adds the mixin modules A and B to all instances of D defeating the purpose of the exercise.

You can actually create a new anonymous class with the modules A and B included but I couldn’t figure out a way to get this class to extend D inline without D itself being a Module.

mixins_without_d = Class.new { |cls| 
   [A, B].each { |mod| self.class.send :include, mod } 
}

That aside, Scala still has on more trick up it’s sleeve: a static type system.

It’s not really worth bringing up the static verses dynamic type systems debate here, but this static type system does provide a nice built-in mechanism for specifying what kinds of objects the trait can be mixed into.

Way down to mixico

Let’s take and example of cat-like behavior.

In Ruby:

module CatLike
  def pur
    "purrrrrr"
  end
  def meow
    "meeeowww"
  end
end

And in Scala:

trait CatLike {
  def pur = "purrrrrr"
  def meow = "meeeowww"
}

Let’s mix in this behavior.

class Tiger
  include CatLike
end

and in Scala:

class Tiger extends CatLike

The nice thing about mixins that that they can be reused in other objects. Let’s try that.

class Spoon
  include CatLike
end

And in Scala:

class Spoon extends CatLike

Hey! Spoons aren’t very cat-like! Let’s revisit our CatLike mixin.

Me-ouch

In Scala, we can declare what types of objects a trait can be mixed into with self types.

trait Feline
trait CatLike { this: Feline =>
  def pur = "purrrrrr"
  def meow = "meeeowww"
}

Now, let’s try that one more time.

class Tiger extends Feline with CatLike
class Spoon extends CatLike // compile time error!

You can technically do this in Ruby, although you need to cleverly invent your own technique.

module Feline
end
module CatLike
  # how often do you see module authors write code like this?
  def self.included(other)
    raise TypeError.new(
      "%s was not a feline" % other
    ) if !other.included_modules.include?(Feline)
  end
end

class Tiger
  include Feline
  include CatLike
end

class Spoon
  include CatLike # TypeError: Spoon was not a feline
end

Not only is that more verbose, but it requires a metaprogramming trick. The Scala implementation also won’t even compile. A client of the Ruby version of CatLike will not find the error until the class is required.

To be fair I am using static type system idiom for filtering, using a type as inference to what kinds of behavior should be allowed. Let’s revisit that once again with rubyism for determining type: respond_to?.

module CatLike
  # more Ruby-like but still not very common for module authors
  def self.included(other)
    raise TypeError.new(
      "%s did not respond to %s" % [other, "whip_tail"]
    ) if !other.respond_to? :whip_tail
  end
  def pur
    "purrrrrr"
  end
  def meow
    "meeeowww"
  end
end

class Tiger
  def whip_tail
    puts "tail whippin'"
  end
  include CatLike # what? TypeError: Tiger did not respond to whip_tail. Yes it does!
end

The module author thumbs through their copy of the Ruby manual. Whoops! Other in this context is a class object, not the instance of a class.

Let’s revise that module one more time.

module CatLike
  # again, more Ruby-like but even still not very common for module authors
  def self.included(other)
    raise TypeError.new(
      "%s did not respond to %s" % [other, "whip_tail"]
    ) if !other.instance_methods.select { |method| method == :whip_tail }
  end
  def pur
    "purrrrrr"
  end
  def meow
    "meeeowww"
  end
end


class Tiger
  def whip_tail
    puts "tail whippin'"
  end
  include CatLike # ok
end

Can Scala play the duck typing game with cats? Surely it’s going to be way more difficult in a ridged staticaly typed language and we will have to resort to some ugly and verbose reflection code.

Let’s revise our scala mix in using the same type of Rubyism.

trait CatLike { this: { def whipTail } =>
  def pur = "purrrrrr"
  def meow = "meeeowww"
}

class Tiger extends CatLike {
  def whipTail = println("tail whippin'")
}

What’s this? This looks a bit more consise than the Ruby implementation while using a Rubyism and it’s statically typed.

Summary

Though this was a trival example of using mixin composition, I hope we covered some of the strengths of using Scala’s traits as mixins: inline object composition and a built-in means of mixin restriction.

Mixin composition is common in many Ruby libraries, though many module authors don’t restrict the types of objects a module can be mixed into which sometimes leads to meowing flatware.

Most language design exclusions in Ruby can be be worked around using metaprogramming techniques which is really powerfull but sometimes leads to indirectly verbose code, skewing attention away from the original intent of the code.

On most days, if I end out writing less code to do the same task, I consider that a day well spent.

an old man and a park bench

Tue, 23 Mar 2010 01:07:00 -0400

I sat down next to an old man on a park bench today. He said to me:

Are you just going to sit there?

So I said:

Why do you ask?

To which he replied:

I’m an old man. These days, what I enjoy most is to sit here and watch others go about their business, over and over, and over again.

I went on my way. I came back to the bench the next day and the old man and the bench was gone.

So I build myself a new bench to sit and watch on my own, occasionally glancing at my watch.

To Build a Bench

I bought a hammer and a few planks of wood and this is what I made:

package park

trait Bench {
  object Timing {
    case class Time(cpu: Long, user: Long, system: Long, real: Long) {
      val tuple = (cpu, user, system, real)
      def - (t: Time) = Time(
        cpu - t.cpu, user - t.user, system - t.system, real - t.real
      )
      def + (t: Time) = Time(
        cpu + t.cpu, user + t.user, system + t.system, real + t.real
      )
    }
    def cpu = get(bean getCurrentThreadCpuTime)
    def user = get(bean getCurrentThreadUserTime)
    def real = System.nanoTime
    def system = cpu - user
    def now = Time(cpu, user, system, real)
    val empty = Time(0l, 0l, 0l, 0l)
    def get(fn: => Long) = if(bean isCurrentThreadCpuTimeSupported) fn else 0l
    private val bean = java.lang.management.ManagementFactory.getThreadMXBean
  }

  def watch(n: Int, o: Int) = { 
    headers
    for(i <- Stream.range(0, o)) collect(n)
  }

  def collect(times: Int) = tell(subject, (Timing.empty /: observe(times))(_+_))

  def subject = getClass getName

  def observe(n: Int) = for(i <- Stream.range(0, n)) yield time { run }

  def time(block: => Any) = {
    val before = Timing.now
    block
    val after = Timing.now
    after - before
  }

  def headers = println(
     (" "*subject.size)+"\t\tcpu\t\tuser\t\tsystem\t\treal"
   )

  def tell(subject: String, time: Timing.Time) = {
    def sec(n: Long) = n / 1000000000.0
    val (cpu, user, system, real) = time.tuple
    println(
      "%s\t\t%f\t%f\t%f\t%f" format(
        subject, sec(cpu), sec(user), sec(system), sec(real)
       )
    )
  }

  /** where unicorns do run wild */
  def run
}

Bird Watching and other Leisurely Observations

I stepped back to have a look at this new park bench.

From here, I can watch flocks of inline invokations fly by, one or more times.

scala> val b = new Bench { def run = 1+1; override def subject = "plus" }
scala> b watch(2, 2)

I jotted down what I saw.

            cpu             user        system     real
plus        0.000067        0.000027    0.000021   0.000046
plus        0.000054        0.000028    0.000021   0.000108

Under a tree, I can watch those pass the time by reading favored books.

object BookShelfBench extends BookShelf with park.Bench {
  def run = read(Book("a tale of two cities"))
  override def subject = "reading"
}

BookShelfBench watch(10, 1)

To be honest, I really didn’t have time to watch them finish this book.

              cpu      user     system   real
reading        a       really   long     time...

This was just a quick and silly re-composition of an idea I had while glancing at scala.testing.Benchmark. This idea may become a real project as some point on the githubs. For now it was just flash coding. Isn’t composition fun?

scope escaping shadow of peter pan

Mon, 22 Mar 2010 00:28:46 -0400

I just thought the error message the following code generates was a little silly.

object PeterPan {
  private case class Shadow(length: Int)
  def shadow = Shadow(10)
}

error: private class Shadow escapes its defining scope as part of type PeterPan.Shadow

an applied case for red ninjas

Sat, 20 Mar 2010 14:24:00 -0400

One of my favorite things about scala are case classes. Those coming from a java background might be used to writing code like this.

public class Ninja {
  private int experience;
  private List<Weapon> weapons;
  private String color;

  public Ninja(int experience, List<Weapon> weapons, String color) {
    this.experience = experience;
    this.weapons = weapons;
    this.color = color;
  }

  public int getExperience() {
    return experience;
  }

  public String getColor() {
    return color;
  }

  public List<Weapon> getWeapons() {
    return weapons;
  }
}

This is commonly known as the bean style of class design. For now, I’ll leave out the mutating setABC(D d) methods that make beans mutable. Code formatting may vary, but for this example, let’s call that 23 lines of code (counting spaces) to define a type with three properties.

Scala has a built-in, more simplified, idiom for this style of class design called case classes. To define the same class in scala we would write

case class Nina(experience: Int, weapons: List[Weapon], color: String)

Again, formatting may vary, but for this example let’s call that one line of code. This bit of syntactic nicety also provides us with a complementary apply method that takes as its arguments the same as the constructor’s so that we can create our classes sans the new keyword by applying the arguments to our Ninja class with:

Ninja(10, List(new Sword), "red")

Building an Army

Now lets say you want to build an army of red ninjas. You might find it more convenient to write an auxiliary constructor in the java class such as

  public Ninja(int experience, List<Weapon> weapons) {
    this(experience, weapons, "red");
  }

Now you can build your army with:

List<Ninja> redArmy = new ArrayList<Ninja>(){{
 add(new Ninja(50, Arrays.asList(new Sword())));
 add(new Ninja(60, Arrays.asList(new Bow())));
}};

Scala too, has its own way of declaring auxiliary constructors by adding methods to classes in the form

def this(experience: Int, weapons: List[Weapon]) = this(experience, weapons, "red")

Case Confusion

Recently, I ran into a gothca with auxiliary constructors in case classes.

Say we add an auxiliary constructor to the Scala version of Ninja as:

case class Ninja(experience: Int, weapons: List[Weapon], color: String) {
  def this(experience: Int, weapons: List[Weapon]) = this(experience, weapons, "red")
}

When you invoke Ninja(10, List(new Sword())) you will get

error: wrong number of arguments for method apply: (Int,List[Weapon],String)Ninja in object Ninja

wtf?

What you are actually invoking there is Scala’s implicit apply method with two arguments.

Ninja.apply(10, List(new Sword()))

If you’ve been paying attention the case class has not generated that for you. Okay, so let’s go ahead and add one to our Ninja case class.

def apply(experience: Int, weapons: List[Weapon]) = new Ninja(experience, weapons)

This time when you invoke Ninja(10, List(new Sword())) you should see the error:

error: wrong number of arguments for method apply: (Int,List[Weapon],String)Ninja in object Ninja

A Friend of a Companion

Turns out the convenience of case classes also adds one restriction to defining them: case classes can only have one apply method which is defined by the primary constructor’s arguments.

Great. So now what? Oh yea, classes can have friends too. They are called companion objects.

We can work around this constraint a companion object.

object Ninja {
  /** I can haz called the auxiliary constructor of the case class Ninja */
  def apply(experience: Int, weapons: List[Weapon]) = new Ninja(experience, weapons)
}

Ninja(10, List(new Bow())) // -> I win!

Now we’re are ready to fight.

Ninja(50, List(new Sword())) :: Ninja(60, List(new Bow())) :: Nil

Have you any other suggestions?

implicitly subtle imports

Mon, 15 Mar 2010 22:58:57 -0400

One of Scala’s cheekier features, implicit declarations, can sometimes conjure up subtle gotchas. Besides being infamous for being a pimp, Scala’s implicits are also play the role of a magician by providing the illusion of default function arguments, a first class feature in 2.8.

I recently came across a subtle gotcha when using implicit function arguments, but first, it might be useful to catch up on a little background about Scala’s implicits.

Implicit wha?

One of Scala’s strong suits is freeing your tired little fingers from typing guessable information by inferring certain aspects about your code.

This same inference feature can provide you with the ability to sprinkle code with hints that will tell the compiler how to react to certain syntactic events, making statically typed code feel more dynamic.

Take the follow example of an implicit definition adds a ridiculous contrived BoomLike behavior to all strings

class BoomLike(str: String) {
  def boom = " %s ka-blam!!" format str
}
implicit def string2BoomLike(str: String) = new BoomLike(str)

You can now magically call the method boom on any String value.

"kitten".boom // kitten ka-blam!!

Implicits can also be used to define arguments in function definitions.

The following function will implicitly apply an implicitly defined value of b to the curried function fn

def fn(a: Int)(implicit b: Int) = a + b
implicit val b = 3
fn(2) // 5

What implicitly got me

I recently came across a use case for implicit function arguments that made me scratch my head.

Let’s say you have written shiny new library. This shiny new library contains some functions that you want to apply implicit defaults values for. You don’t want to obtrusively pollute the top level name space with them so you wrap them up in a module called Defaults. The result of this shiny new library might then look something like the following:

object Defaults {  
  implicit val height = 10
  implicit val frog = "geroro"  
}
def hop(distance: Int)(implicit height:Int) = distance * height

Pop quiz! What do you expect the execution of each to return?

// fig: A
import Defaults.height
hop(20)

// fig: B
import Defaults._
hop(20)

Time is up, kids!

When you to try and hop with figure A, you would fail miserably with an error stating:

error: no implicit argument matching parameter type Int was found.

You might find this odd, considering the value height is visible.

Were to you try and hop with figure B, you would get a value of 200.

I can’t yet provide a reasonable explanation of why. Can you?

37 salad dressings

Sat, 13 Mar 2010 18:11:00 -0500

I’m thinking of a spork with no knives

As a younger man, one of my favorite types of restaurants to eat at were buffets. What can be better than an endless supply of everything? I pay one price and get as much as I want. So many choices!

As I got a little older, I started noticing a couple things about these types of restaurants. For starters, I never actually ate everything on the menu. I would go in and usually get the same thing every time. It was the idea that I could have anything that was so alluring, not the fact that I actually ever ate everything. Over time I realized that the few things I actually did eat at buffets were actually pretty low in quality compared to a restaurants that solely made just one type of food.

Complexity leads to anger. Anger leads to hate. Hate leads to suffering.

Now that I am older, I am more aware of these things as they apply to other areas of my life and have come to appreciate single purpose things.

Of late, I’ve been thinking about this a lot as it applies to software.

I love software. I love writing software. I love reading software, but one of my biggest problems with software is when it wants to do everything. A huge side effect of this type of software is that it tends to be unnecessarily slow. Slow software makes for very angry bears in a campground with no jars of honey. People will get hurt.

How does software get to be slow? How can we make it faster?

The answer should be simple. Do less. If you think your library is already pretty fast, how do you make if faster? The answer is also pretty simple. Do even less. Reduce your complexity and make your code faster. Just ask John Resig.

A while back, I read a short book about a company who has had pretty good success with writing less. Hey Bob! That’s crazy talk! How can you be successful by having less features?

Less features means less running code. Less running code means less places where things can go wrong. Less things going wrong means stable software. Fast stable software makes for happy bears, content with sweet jars of honey.

Castle in the sky

The dream of O(bject)O(rientation) was to have these small interchangeable software modules that we could bind together to build bigger systems as we did as children building castles and helicopter robots with our lego sets.

In a the giant Library of Congress of fat open source magic box abstractions, some of us might have noticed that the promises these libraries make often lead to frustration. How often do you find there is at least one problem of the many a library tries to solve that does not suit our needs? Trying to hack around this one thing tends to break more than it fixes because it was not the original intent of the aforementioned library.

The idea of an abstraction is to make a complex problem simple. That is not a bad thing. If it were, we’d all be working with byte arrays rather than objects types. Abstractions allow us to be more productive by focusing more the the problems we are trying to solve rather than low level details. One thing we should be focusing on is giving these library abstractions a more narrow focus.

I mainly deal my codings cards in the game of Uno called called web software. By web software I usually mean web frameworks. It’s made me happy to see a few great single purpose pieces of software have popped up in the past year or so to provide a simple, common, modular substrate for web frameworks to build on top of. You can bet your gingersnap cookies that I’ve got something similar for scala baking in my kitchen. On the other hand, what makes me unhappy is to see that there is still a bevy of web frameworks out there that will lock you into a trap. The trap is providing you with a buffet of features, most of which you will probably not be using in the end.

I’d like to put in an order for take out

If there is one thing I’d love to see in the future, it’s more high-quality single purpose software working together as loosely coupled modules rather than one monolithic box full of assumptions about my needs.

Most of the time I prefer to build my own castle with a box of colored legos over moving into the same prefab one all of the other dev’s on my block live in. If I do have to move into a prefab one, it had better be easy for me to convert into a giant helicopter robot. If not, I’d like to submit a bug.

a soft sea

Braindump: The Twitter stack

Coderspiel: Testing Scala Libraries

Some ways to write function literals in Scala

giter8 0.3.2 - implicit.ly

I think we can manage

The source of the problem

Simple, the way nature intended it

Fast forward, Let’s git to the point

Heroku me loco

411s, InputStreams and chunked content

sticking ? where it doesn't belong

flex time

mime seating arrangments on airplanes

magic match sticks and burnt fingers

Holy Blinking MAGENTA

a paraphrased back-in-my-day

a Scala crayon box

a well formed cupcake

sweet teething

please yield to passing monads

That’s Monad not Nomad

Are You or Are You Not Comprehending

This Ain’t your Mom’s Dad

For Tickling Monads

referential transparencies

Functional Projectors

Mixed Flavors

Border Crossing

Back to Our Story

Overlapping Transparencies

a transitional suitcase for source

does a cat’s pur make a sound if no one is around to hear it

a transitioning suitcase

there are only some ways to mix a cat

A newish mixology

Mix ins and outs of Scala and Ruby

Way down to mixico

Me-ouch

Summary

an old man and a park bench

To Build a Bench

Bird Watching and other Leisurely Observations

scope escaping shadow of peter pan

an applied case for red ninjas

Building an Army

Case Confusion

A Friend of a Companion

implicitly subtle imports

Implicit wha?

What implicitly got me

37 salad dressings

I’m thinking of a spork with no knives

Complexity leads to anger. Anger leads to hate. Hate leads to suffering.

Castle in the sky

I’d like to put in an order for take out

The `source` of the problem

Fast forward, Let’s `git` to the point