aaron.harnly.net

Lazy vals were an excellent addition to Scala 2.6.0. They allow you to defer calculation of a value until it is actually needed, after which the calculated value is cached.

Unfortunately, this doesn’t play so well with another wonderful Scala feature — implicit parameters. It’s often the case that you’ll want to defer resolution of an implicit until a method call, rather than in the scope of object creation. But lazy values cannot take any parameters, implicit or otherwise — so it seems you’re stuck.

Memoized to the rescue! This is a simple helper class that takes care of the caching of a result. Where you might have had the following method with an implicit parameter:

def foo(implicit bar: Bar): ResultType = { ... }

you instead write the following:

private var _foo = Memoized[ResultType]
def foo(implicit bar: Bar) = _foo or { ... }

(complete source below the fold) Read the rest of this entry »

…write a JavaDoc Doclet so I can use Markdown instead of nasty old HTML in source code comments. How nice would that be?

While we’re at it, somebody oughta write a Markdown plugin for Apple Mail, too. But I think that somebody should be me, so I’ll put off thinking about it for awhile.

…write a JavaDoc Doclet so I can use Markdown instead of nasty old HTML in source code comments. How nice would that be?

While we’re at it, somebody oughta write a Markdown plugin for Apple Mail, too. But I think that somebody should be me, so I’ll put off thinking about it for awhile.

I’ve put together a stub of a TextMate bundle for Scala.

At the moment, it just contains a bare-bones language definition, a template for Ant tasks, and a couple of snippets. I’d like to keep improving it, and would welcome suggestions and modifications.

I’ll be setting up anonymous SVN access one of these days (yeah, right), but for the moment, you can download the bundle directly:

ScalaAWH.tmbundle.zip

NLTK, the “natural language toolkit” for Python, is a wonderful lightweight framework that provides a wealth of NLP tools. The other day, in reading through its documentation, I came across a little appendix describing the advantages of Python for implementing and (especially) teaching NLP.

The authors show a simple sample program to find and list words ending in “ing” from the standard input:

import sys for line in sys.stdin.readlines(): for word in line.split(): if word.endswith('ing'): print word

and contrast this elegant Python implementation with a variety of monstrosities in other languages. I won’t disagree that the Python is nice, but it seemed like a good little exercise to see whether I can’t produce something almost as good in my languages de jour.

To wit, a Ruby version: for line in ARGF for word in line.split if word.match(/ing$/) then puts word
end end end

which is almost identical to the Python version, though showing Ruby’s not-exactly-pretty fascination with the ‘end’ keyword.

And a Scala version using for-comprehensions. Note to Scala creators: It’s really frustrating having the various ways of executing Scala — as a script, as an object, etc. — all disagree slightly on how the outermost wrapper of a procedure should be formatted.

import scala.io._ object IngWords extends Application { for ( val line <- Source.fromInputStream(System.in).getLines; val word <- line.split(" "); word.endsWith("ing") ) Console.println(word)
}

(Aside: I need a decent syntax highlighting package for WP, it seems.)

NLTK, the “natural language toolkit” for Python, is a wonderful lightweight framework that provides a wealth of NLP tools. The other day, in reading through its documentation, I came across a little appendix describing the advantages of Python for implementing and (especially) teaching NLP.

The authors show a simple sample program to find and list words ending in “ing” from the standard input:

import sys for line in sys.stdin.readlines(): for word in line.split(): if word.endswith('ing'): print word

and contrast this elegant Python implementation with a variety of monstrosities in other languages. I won’t disagree that the Python is nice, but it seemed like a good little exercise to see whether I can’t produce something almost as good in my languages de jour.

To wit, a Ruby version: for line in ARGF for word in line.split if word.match(/ing$/) then puts word
end end end

which is almost identical to the Python version, though showing Ruby’s not-exactly-pretty fascination with the ‘end’ keyword.

And a Scala version using for-comprehensions. Note to Scala creators: It’s really frustrating having the various ways of executing Scala — as a script, as an object, etc. — all disagree slightly on how the outermost wrapper of a procedure should be formatted.

import scala.io._ object IngWords extends Application { for ( val line <- Source.fromInputStream(System.in).getLines; val word <- line.split(" "); word.endsWith("ing") ) Console.println(word)
}

(Aside: I need a decent syntax highlighting package for WP, it seems.)

I’m so used to the each_line idiom in Ruby, I felt utterly lost in Scala without it.

Here’s an approximation of it, though I’d love to hear that there’s an even more scala-ish (scalic?) way of doing this:

def eachline(stream : InputStream)(f : String => Unit) { val buf = new BufferedReader( new InputStreamReader( stream ) ) var line = buf.readLine while (line != null) { f(line) line = buf.readLine } }

I use this with a block as so: eachline(System.in) { line => Console.println(line) }

Not bad, but it could be better, I think. Can I tickle this to be a method on streams, instead of a funny little function sitting on its own?

I’m so used to the each_line idiom in Ruby, I felt utterly lost in Scala without it.

Here’s an approximation of it, though I’d love to hear that there’s an even more scala-ish (scalic?) way of doing this:

def eachline(stream : InputStream)(f : String => Unit) { val buf = new BufferedReader( new InputStreamReader( stream ) ) var line = buf.readLine while (line != null) { f(line) line = buf.readLine } }

I use this with a block as so: eachline(System.in) { line => Console.println(line) }

Not bad, but it could be better, I think. Can I tickle this to be a method on streams, instead of a funny little function sitting on its own?