il codice

Idea: Validation + Adapters for Terminal Programs and Web Services

Tue, 01 Nov 2011 13:18:08 -0400

Derive a common utility or library for options and constraints from something like scopt and Unfiltered’s parameter validation library. With a common way to specify input arguments, functions to produce boiler plate for command like programs and web endpoints would be easy to write. This would be a great use for scalaz / validation.

Too much curry!

Sat, 27 Aug 2011 19:38:00 -0400

What does a compiled curried method in Scala look like in java? Compile this:

object Concat {
  def concat(s: String)(ss: String) = s + ss
  def concat(s: String)(i: Int) = i + s
}

Now inspect the resulting class with javap:

Compiled from "Concat.scala"
public final class Concat extends java.lang.Object{
    public static final java.lang.String concat(java.lang.String, java.lang.String);
}

After compilation curried methods look like normal, multi-parameter methods. It doesn’t matter how many parameter lists you define, nor how many parameters each list takes; in the end you get a plain old method. Knowing this we should expect overloading to work fine, so let’s overload our curried method:

object Concat {
  def concat(s: String)(ss: String) = s + ss
  def concat(s: String)(i: Int) = i + s
}

As expected, this compiles, and javap gives expected output:

public final class Concat extends java.lang.Object{
    public static final java.lang.String concat(java.lang.String, int);
    public static final java.lang.String concat(java.lang.String, java.lang.String);
}

Great, let’s use it!

object Concat {
  def concat(s: String)(ss: String) = s + ss
  def concat(s: String)(i: Int) = i + s
}

object Concatter {
  def greet(who: String, msg: String) = Concat.concat(who)(msg)
}

And compile:

Concat.scala:7: error: ambiguous reference to overloaded definition,
both method concat in object Concat of type (s: String)(i: Int)String
and  method concat in object Concat of type (s: String)(ss: String)java.lang.String
match argument types (String)
  def greet(who: String, msg: String) = Concat.concat(who)(msg)
                                               ^
one error found

Well, that was unexpected! The compiler let us overload a curried method, but it won’t let us use either of them. The error tells us that the compiler is unable to disambiguate the method. This seems strange as we’re explicitly passing values for all arguments. Try as we may, there simply is no way to use these methods as defined. As it turns out, this is a problem of scope. Let’s try different access modifiers:

object Concat {
  def concat(s: String)(ss: String) = s + ss
  protected def concat(s: String)(i: Int) = i + s
}

object Concatter {
  def greet(who: String, msg: String) = Concat.concat(who)(msg)
}

This compiles because Concat.concat(s: String)(i: Int) is not in scope at the call site (it’s not accessible). However, within Concat both are in scope:

object Concat {
  def concat(s: String)(ss: String) = s + ss
  protected def concat(s: String)(i: Int) = i + s
  def con = concat("")("")
}

Concat.scala:4: error: ambiguous reference to overloaded definition,
both method concat in object Concat of type (s: String)(i: Int)String
and  method concat in object Concat of type (s: String)(ss: String)java.lang.String
match argument types (java.lang.String)
  def con = concat("")("")
            ^
one error found

If you’re overloading curried methods, remember that you must demarcate their potential scopes with access modifiers. Two overloaded curried methods with the same access levels will never be callable; they will compile unless you try to use them. Perhaps a more fundamental lesson to learn from this is to eschew method overloading in general, always.

"There’s always a “best” tool for any job, but if programmers don’t know how..."

Fri, 22 Jul 2011 12:13:05 -0400

“There’s always a “best” tool for any job, but if programmers don’t know how to use it, they’ll choose an inferior tool because they think their schedule doesn’t permit a learning curve. In the long run they’re hurting their schedules, but it’s hard to see that when you’re down in the trenches.”

- Steve Yegge

Moving to New York City

Tue, 12 Jul 2011 19:54:41 -0400

For several years now I’ve felt that, at some point, I’d like to move to New York City. I visited the city for the first time in 2009, and I was just taken. Its history, strength, character, diversity, and cultural wealth captivated me.

Still, there was something else. I had just recently discovered the Scala programming language. I’m a polyglot programmer but I’ve spent a lot of time on the jvm. When I was exposed to Scala, my first reaction was merely: “Wow, this is cool!” And then the paradigm shift began as I inadvertently embarked on a mind-altering journey into the world of functional programming. It’s been frustrating, illuminating, continuous, and it just keeps going.

But I digress. One of the reasons that I’m moving to New York is that there are many bright, passionate people that make up a vibrant community of programmers; functional and aspiring-to-be alike. It is a place where exploring concepts with others is easier; a place where cross-pollination of ideas and paradigms common. What’s more, there are companies building great products that are harnessing this energy (like the one I’m joining). I’ll be making the switch from full-time Java to full-time Scala, and while I’m new to the company’s industry, I’m no newbie to Scala. I’m full of an excitement laced with a bit of healthy fear, and I can’t wait to start.

"If anything were actually “immeasurable,” it would bear no relationship of any kind to..."

Tue, 28 Jun 2011 11:11:27 -0400

“If anything were actually “immeasurable,” it would bear no relationship of any kind to the rest of the universe, it would not affect nor be affected by anything else in any manner whatever, it would enact no causes and bear no consequences - in short, it would not exist.”

- Ayn Rand

Making Meetup: Real-life Meetups Deserve Real-time APIs

Tue, 25 Jan 2011 17:21:20 -0500

Making Meetup: Real-life Meetups Deserve Real-time APIs:

makingmeetup:

First things first, open a linux or mac terminal and tap into the RSVPs stream:
curl http://stream.meetup.com/2/rsvps
What you’re seeing now is each RSVP to a public Meetup group as we receive it. When a user clicks an RSVP button or an application calls the RSVP method, the server handling the…

Best. Gift. Ever.

Sat, 01 Jan 2011 12:45:40 -0500

Last night, Erin and I opened presents that had arrived in the mail from my parents. One of them was a folded, unassuming manilla envelope, and inside was another folded manilla envelope. I unfolded the inner envelope to reveal a 5x5 floppy disk which, at first, confounded me. Looking at its label I immediately recognized my mother’s handwriting; it identified the disk as “Chris’ Game.” It was accompanied by a note from her, stating “The floppy disk may have Chris’s first programming efforts - a game in Q-basic, I think.” These simple words are precious.

My family is not one of technophiles, and in fact they might be better described as technophobic. They worked at a small college with a quaint computer lab, and one day a friend told me I could use that to make a game. My mind was blown! He then introduced me to the computer that would become my first workstation: an IBM (compatible) 80286 with a turbo switch. It was running a later version of DOS with a menu-driven UI called DosShell. Having almost no previous exposure to computers, I didn’t know how to be picky.

My friend didn’t know much, but he knew that much more than I did. He showed me how to navigate the system, how to start the QBasic environment, and how to evaluate simple statements (print to the screen, basic operators and math functions). I didn’t know what any of this stuff was, but I soaked it up with wonder and learned quickly. I don’t remember the exact date, but this must have been in the summer of 1992 or 1993. In the following weeks I spent countless solitary hours exploring the computer, spending most of my time in QBasic. A day or two in, I started writing my game.

I remember this game. I remember its source code. It was a text-based game of monsters, magic, and battle. I remember the depression I felt when I concluded that it was impossible to randomize the output of a fight, a problem on which I had spent a day or two hacking to no avail. And then I discovered the interpreter’s help system, which eventually led me to the RAND function (a pseudo-random number generator). This proved to be a solution to my problem, and behold, nondeterministic battles! Anything was possible! I did what I wanted, coding with pure joy and blissfully ignorant of any consequence other than bugs in my game. Everything I did, I did to make the game better: I added stronger monsters, magic, shops, items, weaponry, and commerce (you could buy and sell items and weapons). It was awesome! More than awesome, it revealed a lasting passion in me at a fairly young age: I loved to program.

I’ve received many gifts of sentimental value in my life, but never one I’d describe as “grounding.” In a month I’ll be 30 years old. 30! We change and we grow, and sometimes an analysis of who we are compared to who we were leaves us puzzled. To hold this 5x5 floppy disk in my hand; to reflect on the stumbling, clueless child that I was as I elatedly copied my source code to and from its magnetic memory some 17 years ago is truly grounding. What lies encoded on this disk is an immutable fragment of me; a reminder of who I am. I cannot imagine a better gift!

Happy New Year to all. To open 2011 I impart this simple declaration to myself and you all alike:

Do what you love and do it with passion. If you aren’t happy, do something else.

Anxiety 2.0

Tue, 28 Sep 2010 01:14:00 -0400

Last weekend I attended the first annual WebDirections USA conference, in Atlanta, GA. My primary takeaway is that JavaScript on the server side will continue to make enormous gains comparable to those made by rails when it first appeared on the scene.

Yeah, that’s huge.

Of all the sessions, NodeJS and the expert panel resonated with me over the rest. The node session was a simple, thorough primer; nothing of any apparent philosophical value. However, the expert panel, and specifically a bold assertion made by Tantek Çelik, sent my head into overdrive. His thesis: in 5 years, every server side language will be dead or dying, being replaced by JavaScript. For a split second I merely giggled, and then I went somber; pensively spiraling into a future far different than the one I had imagined, and certainly different from the one I wanted to see.

This assertion did not sit well with me. The rails phenomenon shocked the web world, in many ways for the better, but it is a phenomenon I have never fully embraced.

On Friday night I engaged Tantek about this issue, hoping to gain a better understanding of his perspective, as well as my own, since he had dealt me a debasing blow. He clarified his prediction: in 5 years, all other language communities will have ceased to grow, and likely be in recession. Why? Ubiquity. JavaScript is the most widely deployed language on the planet, and huge numbers of people have at least some knowledge of it, as well as CSS and HTML. It is also a comparatively productive and relatively simple language, converging on what seems to be critical mass.

What do you get when you mix ubiquity, simplicity, and productivity? World takeover. Well, maybe.

I take issue with this idea. I have not yet fully formed my opinion, but the thought does cause me a bit of anxiety, and I shared this with Tantek.

What’s my deal? Am I sour that my preferred languages are not on the forefront of the next apparent revolution in web development? Maybe a little, but that’s hardly the crux of it.

Typing (integer.sayHello())
This is a battle that goes back decades. Dynamic interpreted languages are popular for at least two reasons: they are, or rather, they seem to be, simpler to learn and use, and they are more productive in the day-to-day development cycle. I am perhaps a minority among my fellow generation Yers in that I prefer static typing. No, I don’t like superfluous typing and no, I don’t merely want a static hint at what an argument is capable of (though you could make a fair argument for this). I prefer static typing because it is inherently more correct.

Static typing guarantees that, in terms of the expressed capabilities of a program’s abstractions, the calls made on these abstractions are logically sound. That is, during the compilation phase, if you call a method sayHello on an instance of Integer, the compilation will fail. It simply isn’t possible to make this mistake.

Further, many dynamic languages (PHP, ruby, python, javascript, …) allow arbitrary changes to arbitrary references throughout a program’s abstractions. That is, given an object Math which contains a reference PI, such that Math.PI equals 3.14159, it is possible for any piece of code to change that reference, such that Math.PI might then be 42, or 0, or “some arbitrary value of some arbitrary type.” In fact this practice, “monkey patching” as pythonistas call it, is embraced in many of these communities. You might call this flexibility, but on a good day I call this a poor facility for abstraction, and on other days insanity.

In a static language, this is simply not allowed. Some languages, specifically Scala (via implicit conversions), provide this same kind of structural flexibility without sacrificing static integrity. Static typing has a historical stigma of pain, but it is has improved in leaps and bounds. I only hope we haven’t lost the attention of developers.

Null (i = null; i.toString())
JavaScript, like most languages, supports the notion of a null pointer (or null reference). In most languages, including JavaScript, no tool will help you avoid this. Any object can be assigned this value, even in most static languages, in which it is viewed as a subtype of all types. In such an environment, a null pointer is a ticking time bomb. You get no help from tooling, so if you forget to check something (and we do this all the time), you get a runtime error. Seasoned developers struggle with this; it is a non-intuitive problem. On the other hand, many functional languages (like Scala and Haskell), employ monadic types to remove this problem.

The problem of null is neither new or superficial. The inventor of this concept, Sir Charles Antony Richard Hoare, spoke to an audience about the history of null, regarding it as a “billion dollar mistake.” Incidentally, he also says quite a lot about static typing in that talk, so I do suggest watching it.

Concluding
I think Tantek might be right, even if in a slightly lessened fashion. Further, while the future I want to see differs from the one I feel impending, I’m not in despair. Rather, I’m currently enjoying hacking on NodeJS, all the while seeking out what I see as the ideal future.

"By investigating the logical properties of your programming language and finding out how difficult..."

Sun, 26 Sep 2010 01:59:38 -0400

“By investigating the logical properties of your programming language and finding out how difficult it would be to prove correctness if you wanted to, you would get an objective measurement of how easy the language was to use correctly.”

- Tony Hoare

"If the proof of program correctness requires a very large number of different proof rules, and if..."

Sun, 26 Sep 2010 01:55:00 -0400

“If the proof of program correctness requires a very large number of different proof rules, and if each proof rule has a lot of side conditions, in particular, if the validity of the local applciation of a rule to a small bit of program depends on properties which can only be established by a scan of the program as a whole, then you know that you’ve done a bad job as a language designer and you do not have to get your customers to tell you that.”

- Tony Hoare

erinlewis: last month’s snow in Florence. 1:15 looks down our...

Fri, 08 Jan 2010 16:25:42 -0500

erinlewis:

last month’s snow in Florence.

1:15 looks down our old street.

bellissima.

A Look at How Scala Compiles to Java

Wed, 11 Nov 2009 00:43:24 -0500

Consider this contrived example, based on an example from Beginning Scala. The point of the snippet was to demonstrate the congruency between using the higher-order functions map, flatMap, foreach, and filter (see Iterable), and performing the same operations inside a for comprehension.

object App {
	
	def isEven(i: Int) = i % 2 == 0
	
	def isOdd(i: Int) = i % 2 == 1
	
	def main(args: Array[String]): Unit = {
		val n = (1 to 10).toList
		n.filter(isEven).flatMap(i => n.filter(isOdd).map(j => i * j))
	}
	
}

Save this code to a file named App.scala, or anything you want (scala doesn’t have the same file/class name restrictions as java). Assuming you chose App.scala, compile it:

clewis$ scalac App.scala

Now check out the generated class files (ls App*class). You should see the following:

App$$anonfun$main$1.class
App$$anonfun$main$2$$anonfun$apply$1.class
App$$anonfun$main$2$$anonfun$apply$2.class
App$$anonfun$main$2.class
App$.class
App.class

Why were 6 classes compiled from this one singleton definition? Let’s start with App.class and App$.class.

The Singleton Object

Scala does away with Java’s statics. Instead we get singleton objects, which are declared with a syntax similar to that used for class declarations, but using the object keyword instead. When a singleton object shares the same name as a class, it becomes that classes “companion” object. Companion objects have special privileges, including access to private instance fields on instances of the companion type. In this example, App is simply a singleton object, since we haven’t also defined a class named App.

The Scala compiler implements companion objects by generating an anonymous class inside the companion class (the class of the same name as the object). The same is done for singleton objects, but the compiler also generates the containing class. Like the Java compiler, Scala names anonymous the class as [class name]$. Because we created an object named App, we get 2 classes: App and App$.

Higher Order Functions and Their Function Arguments

In Scala, functions are objects; instances of one of the FunctionN traits. Of course this knowledge isn’t obvious by the Scala syntax, and that’s part of the beauty: it just feels right. The compiler compiles any functions down to anonymous classes inside the containing class. If you understand Java’s scoping rules for inner classes, then you should now have some understanding of how Scala implements closures.

Methods in Scala are also different from functions. Methods are functions defined as part of a class definition with the the def keyword. Functions are instances of one of the FunctionN traits, and the Scala syntax provides several different ways to express them tersely. Methods are the only primitives (non-objects) in Scala, but the compiler makes it easy to promote methods to function instances. Back to our example, notice that we define the methods isEven and isOdd in our singleton object. They are method primitives, not functions. Because the compiler recognizes that methods often want to be treated as functions, it makes provisions; one such provision is that we can pass a method to a higher-order function.

Method Promotions

In order for the compiler to promote a method to a function instance, it must create an anonymous class for that instance. In our example, we first pass the method isEven as an argument to the higher-order function filter, and so the compiler generated the class App$$anonfun$main$1, which is our promoted method. Note that we also pass the isOdd to a subsequent call to filter, a promotion for which the compiler generated the class App$$anonfun$main$2$$anonfun$apply$1.

Function Literals

We’ve covered all but 2 of the generated classes. As it turns out, there are still 2 functions we haven’t discussed in the series of transformations. Take another look:

n.filter(isEven).flatMap(i => n.filter(isOdd).map(j => i * j))

Did you see them? If you’re new to Scala, you may not spot them at first because they are using function-literal syntax. The functions flatMap and map also take functions as arguments, and so we define them literally, embedding the one passed to map inside the one passed to flatMap. For these two function literals, the compiler generated the anonymous classes App$$anonfun$main$2 and App$$anonfun$main$2$$anonfun$apply$2.

To seal in what’s happening here, fire up the Scala REPL and run this code:

List(1,2,3).map(j => j + 1)

Now run this code:

List(1,2,3).map(new Function1[Int, Int] {
	override def apply(j: Int) = j + 1
})

The two do the exact same thing, because they are exactly the same.

The literal syntax may look strange, and even non-obvious at first. I thought so too, but it didn’t take long for me to greatly appreciate and recognize it as easily as you might recognize a class definition.

A Word on the Class Names

You may have noticed a pattern in the anonymous function class names. For starters, they’re prefixed with App$$anonfun$main$ and then continue in with 1.class and 2.class. There’s also another level nested inside the first level. If you inspect each of these using javap -c [class], you’ll notice the ordering and nesting follows the order in which we use function objects (by passing them as arguments to other functions).

isEven is the first function we pass, so it is the first function for which an anonymous class is generated, yielding App$$anonfun$main$1.
The second is the literal function passed to flatMap, so App$$anonfun$main$2 is generated for it.
The third is isOdd, yielding the class App$$anonfun$main$2$$anonfun$apply$1. This function is used inside the function passed to flatMap. It’s the first function in this scope, and it’s nested, so its name reflects its nesting and order in the sequence.
Finally we arrive at the literal function passed to map>, resulting in App$$anonfun$main$2$$anonfun$apply$2. It’s the second function referenced inside the function passed to flatMap, and so its name also reflects its nesting and order.

This ordering and nesting is deliberate. In Java, an inner class has access to its parent’s scope, which includes class instance variables and local variables (if the inner class was created in a method). This is what makes closures in Scala possible. Look again at the literal function passed to map:

n.filter(isEven).flatMap(i => n.filter(isOdd).map(j => i * j))

The function multiplies a “free” variable i by its single argument j. Where did i come from? Again, this function is defined inside another literal function passed to flatMap. That function receives a single argument, which it labels i. Because the function passed to map is nested inside the one passed to flatMap, it has access to that scope.

Lift Off

Fri, 30 Oct 2009 08:54:35 -0400

I arrived at the FGM building by way of my couchsurfing host, Jenny. At the moment, Reston looks a bit like London (at least if you look straight up). Fall has painted the leaves brilliantly, a sight I’m left wanting in Florida.

Jenny graciously dropped me off at the FGM building on her way to school (she’s a school teacher). I gladly accepted arriving an hour early for a free ride, and so I just started wandering the office park. I stumbled on this office “cafe” as it were, and here I sit. I seem to be just outside a free guest wifi network, but that’s ok. For a first-timer at an unconference, or any tech conference for that matter, I feel fairly prepared.

I’ve just made my way into the FGM suite. So far we’re about 32-30 strong!

Functional Content Negotiation in Scala

Thu, 15 Oct 2009 22:44:00 -0400

Today I needed some code to assess if an HTTP request matched certain criteria, based on its declared content type. Essentially, I needed to know if the user-agent wanted XML (or JSON), and that it wanted only that type.

Requirements:

Check the Accept request header for a given content type.
Support a non-standard X-Accept header serving the same purpose as Accept (IE doesn’t let XmlHttpRequest specify the Accept header).
The header value is specifically required to be one, and only one MIME type, without an explicit “q” value.

Assuming we have an HttpServletRequest instance that only accepts application/xml:

scala> req.getHeader("Accept")
res6: String = application/xml

and that we have an object with a method implementing the match algorithm, we should see this behavior:

scala> matcher accepts(req, "application/xml")
res7: Boolean = true

scala> matcher accepts(req, "application/json")
res8: Boolean = false

The complete code:

type HttpServletRequest = {
  def getHeader(h: String): String
}

object req {
  def getHeader(h: String) = h match {
    case "Accept" => "application/xml"
    case "X-Accept" => "text/html"
    case _ => null
  }
}

trait Acceptor {

  val headers = "Accept" :: "X-Accept" :: Nil

  def accepts(request: HttpServletRequest, contentType: String) =
    headers map (request.getHeader) filter(_ != null) map {
      _ == contentType
    } reduceLeft(_ || _)
}

object matcher extends Acceptor

Not much, but let’s look at it more closely.

type HttpServletRequest = {
  def getHeader(h: String): String
}

A type alias. This is a structural type, aliased as HttpServletRequest, with a method getHeader(String): String. This makes it easy to prototype the code in the scala REPL, or compile it against javax.servlet.http.HttpServletRequest.

Next, a singleton instance of the aliased type:

object req {
  def getHeader(h: String) = h match {
    case "Accept" => "application/xml"
    case "X-Accept" => "text/html"
    case _ => null
  }
}

This conforms to our requirements above, and also behaves like a real HttpServletRequest in that it returns the dreaded null if no header by the provided name exists.

Next is the trait:

trait Acceptor {

  val headers = "Accept" :: "X-Accept" :: Nil

  def accepts(request: HttpServletRequest, contentType: String) =
    headers map (request.getHeader) filter(_ != null) map {
    _ == contentType
  } reduceLeft(_ || _)

}

Notice the headers val. This is a list of strings containing the header names to read from the request and interpret as Accept header values.

The fun part is the accepts method, which takes a servlet request (conveniently aliased for REPL play), and a content (MIME) type. This is purely functional; there are no side-affects, it is deterministic, and the algorithm is a series of four transformations occurring on one collection after another. Through the transformations, the collection is reduced to a single boolean value. Let’s start with the first line:

headers map (request.getHeader) filter(_ != null)

Starting with the list of header names to inspect in the request, we map it with request.getHeader. This creates a new list, where each element is the result of applying request.getHeader to each element in the original headers list. The original list contains 2 elements, “Accept” and “X-Accept”, and so the resulting list now looks like this: List(application/xml, text/html). Our request object responded to the query for “Accept” with “application/xml”, and “text/html” to “X-Accept.” Had either of those header names not been present, a null value would now be present in the list.

Now we filter this resulting list. Filter, like map, applies a function to each element in the collection and results in a new collection. The function receives each element and returns a boolean value. For each invocation that results in true, that element is added to the resulting list (you filter a collection using a function). We use a literal shorthand to assert that the element is not null, and so the resulting list will contain non-null strings. This filtering is simply protection against null. Our transformed list doesn’t contain any nulls, so the new list looks the same as the old one: List(application/xml, text/html).

Next we have another mapping operation, using brackets instead of parentheses.

map {
  _ == contentType
}

The use of brackets here is a style choice, and in this case is the same as writing map(_ == contentType). This part also evolved from a partial function, where the body is a case statement, matching on the single argument. The function being mapped simply checks if each element is equal to the contentType argument. Remember that == in scala, contrary to java, is an object equality test and not an identity test (eq is for identity tests). We left off at List(application/xml, text/html), and after this mapping transformation, arrive at List(true, false).

The final transformation, simple as it is, actually took me a bit to realize. The function itself had undergone a few iterations, each representing in some way, a group of header values in the request that did or didn’t match a given content type. I couldn’t seem to reach a solution that felt natural. I thought about filtering on true, and then checking that the result list wasn’t empty, but that didn’t really express the essence of the computation. Same for a find (and then matching on Option(true)). They would have worked, but they missed the point and, as all point-missers do, cluttered the algorithm.

Then it hit me:

reduceLeft(_ || _)

Exactly what I wanted. reduceLeft receives a 2 argument function, walks the contents of the collection, and returns the accumulated result. On each invocation, it passes the current and the next element as arguments, progressing from left to right, until the collection is exhausted. The result of one invocation becomes the input to the next. As a simple example, consider list summations:

scala> List(1,2,3) reduceLeft(_ + _)
res14: Int = 6

scala> List(1,2,3,4) reduceLeft(_ + _)
res15: Int = 10

Back to our exmaple, using function-literal shorthand, I OR the two arguments. This means that if either of the two are true, the resulting value is true. Reducing a list of booleans with this function results in a single boolean value. Because I’m using OR, a single true value in the list will result in a true result at the end of the reduction. We left off at a List(true, false), and after our reduction, arrive at a single true result. Perfect.

Last of all, a singleton that mixes in the Acceptor trait.

object matcher extends Acceptor

This just gives us an object with Acceptor behavior mixed in, so we can play in the REPL.

"Great minds discuss ideas; Average minds discuss events; Small minds discuss people."

Mon, 12 Oct 2009 21:59:25 -0400

“Great minds discuss ideas; Average minds discuss events; Small minds discuss people.”

- Eleanor Roosevelt

A Solution to the Set Combinations Problem

Mon, 12 Oct 2009 21:58:13 -0400

def combine[T](sets: List[List[T]]): List[List[T]] = sets match {
  case List(l1, l2) => l1.flatMap(i1 => l2.map(List(i1, _)))
  case head :: tail => combine(tail).flatMap(set => head.map(_ :: set))
  case _ => sets
}

Recursion with an Arbitrary Number of Lists

Tue, 29 Sep 2009 13:00:18 -0400

{ apple, banana }
{ milk, cheese, yogurt }
{ nuts, legumes }

— would result in —

{ apple, milk, nuts }
{ apple, milk, legumes }
{ apple, cheese, nuts }
{ apple, cheese, legumes }
{ apple, yogurt, nuts }
{ apple, yogurt, legumes }
{ banana, milk, nuts }
{ banana, milk, legumes }
{ banana, cheese, nuts }
{ banana, cheese, legumes }
{ banana, yogurt, nuts }
{ banana, yogurt, legumes }

Dependency Injection Using Language-only Constructs

Sun, 16 Aug 2009 22:29:40 -0400

I’ve been exploring dependency injection in Scala. Digesting this article by Debasish Ghosh, I was inspired to play with the code. At the time of the article’s posting it needed a few pieces to compile. You can find the inferred working source here. As an exploratory exercise, I transposed it to java. Chew on it a bit; it clarified some things for me about both the technique and the workings of Scala abstractions.

Vote for ROSA LOVES!

Thu, 16 Jul 2009 16:36:15 -0400

Vote for ROSA LOVES!

Super quick start with Lift's ProtoUser

Mon, 13 Jul 2009 21:44:00 -0400

Lift provides a trait called ProtoUser, which helps you in quickly adding base functionality to your application for user-specific data. The Lift book mentions this class very briefly, but it makes the assumption that the reader will be to intuit how to complete the example code to have a base starting point. Here’s what you must have (assuming this is in the model directory):

package app.model

class User extends ProtoUser[User] with LongKeyedMapper[User] {
def getSingleton = User
}

object User extends User with LongKeyedMetaMapper[User]

You need to mix in the LongKeyedMapper trait, and you need the User singleton.