Object Commando languages, development and design


Clojure Apply

I ran into the following situation a few times, I had a list of items, and I was attempting to call a function that accepted individual items. As an example, I had a list of contact information, where the first element is the contact name, the second, contact info, the third a contact name and so on. This is exactly how the sorted-map function works in Clojure, only it expects the items individually, not the list. The doc for sorted-map is below:

([& keyvals])
keyval => key val
Returns a new sorted map with supplied mappings.

An example of how to call it is something like:

user> (sorted-map 1 2 3 4)
{1 2, 3 4}

What I had instead was something like [1 2 3 4]. An easy way to convert the list to individual arguments is the apply function:

([f args* argseq])
Applies fn f to the argument list formed by prepending args to argseq.

Swapping out the direct sorted-map call for an apply call looks like:

user> (apply sorted-map '(1 2 3 4))
{1 2, 3 4}

Note it returns the same result as calling the function directly. Using apply saved me from writing code to iterate over each item and manually add them to the map.

Filed under: Languages No Comments

Being Lazy with Clojure

I've done development in some other functional languages, but I've done the most development in OCaml. OCaml is a functional language, but not lazy by default. There are libraries that can be used to cause data structures and such to be lazy, but you have to go out of your way to use them. Clojure is lazy by default. One interesting ramification of this is in the lazy lists that it creates. I'm still trying to learn the language, so I figured I'd parse a CSV type of file that contained contact information that I dumped from a contact application I use. I wanted to get the lines in the CSV into a list so I could take a look at them from a Clojure perspective. To do this, I wrote some code like below:

(with-open [rdr (reader "/some/directory/contactinfo.csv")]
(def lst (line-seq rdr)))

The code basically opens the file, executes the code in the body and then closes the file (think of the def lst... part as in the try block). What I was expecting to happen was line-seq to read each line and store it in lst. Much to my surprise, when I attempted to look at the first element of lst, I received an error message:

java.io.IOException: Stream closed
[Thrown class java.lang.RuntimeException]

This pointed out two interesting things to me. First, when I accessed the list (since it was lazy) it tried to pull the first line out of the file. Since I used the with-open function, that file was closed. Next, I realized that if it was trying to read in from the closed file, (line-seq) was not behaving as I was expecting. The book I'm reading by Stuart Halloway did discuss this, I just forgot. My first reaction was to pass a function that does the parsing to the function above. This would cause all of the operations on the file to occur before the closing of the file. The file I was parsing ended up not being easily parsed line by line, since most of the data items spanned several lines. I found the right function was slurp:

([f] [f enc])
Reads the file named by f using the encoding enc into a string
and returns it.

Slurp will just pull all of the file into a String. I was able to differential the contact title from the contact details easily with the Clojure re-partition function:

([re string])
Splits the string into a lazy sequence of substrings, alternating
between substrings that match the pattern and the substrings
between the matches. The sequence always starts with the substring
before the first match, or an empty string if the beginning of the
string matches.

The only trick to using it was to go back through the list and discard the substrings between the matches. I was easily able to do this is the filter function. More on Clojure and lazy lists to come.

Filed under: Languages No Comments

Squeak Going 100% Open Source

Good news for Squeak developers. It looks like they are in the final throws of converting all code to the MIT or the Apache license. They still need an official release before the conversion is complete, but it looks like it's just a formality. There have been several problems with the Squeak License. First, the license has a few clauses that are different than most of the mainstream Open Source licenses. An indemnity clause that could require software distributors to pay legal fees to Apple in case of law suit. Another to add in export restrictions. At one time, some of the pieces could not be used in "for profit" software (like the fonts). So all around good news for Smalltalkers!

Filed under: Uncategorized No Comments

Emacs and Clojure

I'm spending some time learning Clojure and am so far, thoroughly enjoying it. Writing the code is a breeze in Emacs. Historically, Emacs has always been a top notch environment for writing Lisp code. Thanks to the swank-clojure module, writing Clojure in Emacs is just as easy as writing Common Lisp in Emacs. I think this is a great benefit to the Clojure community. One of the problems many languages face is the tool set early in the life of the language. Languages that come to mind are Haskell, OCaml, Ruby, Groovy, JavaFX and so on. Ruby, Groovy and JavaFX are coming along, but early on, it was a struggle. Clojure instead was able to lean on SLIME for that IDE-like support. SLIME has been around for quite a while and already had robust support for Lisp. Since Clojure could leverage this, it got most of the IDE stuff for free.

Filed under: Languages No Comments

Moving On

Yesterday I accepted a position at Revelytix. I'll be starting in March. They're a tech company that is working on Sematic Web technologies. I'm looking forward to the cutting edge technologies and digging into the Semantic web. I'll be working with Alex Miller and a few others as we start on development of a new product. Expect some posts on the Semantic Web, Clojure and Scala!

Filed under: Misc 1 Comment