| Statically Typed Closures In Groovy | 21 Jan 05 | |
| [ print link all ] | ||
Closures in GroovyThere is an interesting debate going on about closures in the Groovy language. You can catch up on the discussion here:
For those who don’t want to read the whole conversation, I’ll summarize the bit I wish to address. Mike is advocating simplification of the Groovy language syntax to remove ambiguities and make have special cases. An admirable goal, no doubt. In addition revoking the optional parenthesis and semi-colons currently sported by Groovy, Mike wants to make the closure syntax more explicit. Currently closures in Groovy look very similar to blocks in Ruby.
list.each { item | println(item) }
Mike would like to see it changed to …
list.each (clos(item) { println(item) });
Where clos is now a keyword that introduces the closure and the closure argument list is given explicitly in a way that is more Java-like. One of the reasons he likes this is that it opens the possibility of declaring the types of the arguments to the closure. Quoting from the third link above:
Wow, a "huge boon". Let’s see how this boon works out in practice. Static Closure TypesWe will start this Mike’s suggested syntax add a return type declaration. This gives us the ability to declare closures like this:
# A closure that takes an integer and returns an integer value.
clos(int i):int { i + 1 }
# A closure that takes a string and returns a integer.
clos(String s):int { s.length() }
# A closure that takes a string and returns no value
clos(String s):void { println(s) }
I think you get the idea.
For static typing to work, we need the ability to declare variables of a given closure type. Here we declare three variables that match the types of the three closures above. clos(int):int integer_func; clos(String):int string_func; clos(String):void handler; Given the above declarations, we should be able to do the following:
integer_func = clos(int i):int { i + 1 }
string_func = clos(String s):int { s.length() }
handler = clos(String s):void { println(s) }
In all cases, the type of the closure exactly matches the declared type of the variable. We will be able to invoke the closures and be certain that there will be no runtime type errors, which is certainly the goal of static typing. Relaxing the Exact Match RuleConsider the following …
interface Animal { void talk(); }
class Cat implements Animal { void talk() { println("Meow") }
Should the following assignment be allowed?
clos(Cat):void cat_handler
cat_handler = clos(Animal a):void { a.talk(); }
Let’s think about this. The closure can handle any type of Animal. The closure variable cat_handler is declared in such a way that only Cat objects can be passed to the closure referenced by cat_handler. Since Cats are Animals, this should cause no type errors at run time. One more example, then we well summarize the rules.
clos():Animal factory;
factory = clos():Cat { new Cat() }
Again, this looks to be type safe. Closures called through the factory variable are guaranteed to return Animals. The closure in question returns a Cat object, which is certainly an Animal. This will cause no type errors at run time. Summarizing the Closure Compatibility RulesWe can summarize the rules for assigning closures to closure variables as follows: A closure can be assigned to a closure variable when:
The above language is way too informal for a real language definition, but I’m trying to get at understanding rather than exact semantics. The rules should do for our purposes. A Real Life ExampleWe now have enough to try some real life examples. Consider the following transform function that takes a list and returns a new list built from an arbitrary transformation on each element. The transform is specified by a statically typed closure.
List transform(List list, clos(Object):Object transformation) {
List result = [];
for (Object current_obj in list) {
Object new_obj = transformation(current_obj);
result.append(new_obj);
}
return result;
}
Our closure is specified in terms of Object because we want it to work on any kind of list. How would we use it? We might like to do the following:
clos(int):int t = clos(int i):int { i + 1 };
transform([1,2,3], t);
Oops! This doesn’t work. The closure t is not compatible with the closure needed by the transform function (it breaks rule 2 above). The closure t only takes arguments of type int, but transform could possibly pass any type to t. Ok, it is pretty disappointing that the direct approach does not work. So let’s try something else. What if we tried this.
clos(Object):int u = clos(Object obj):int { ((int)obj) + 1 };
transform([1,2,3], u);
This works! But at what cost? Are you bothered that we needed a cast to get our closure to work properly? You probably should be, for what we have done is lie to the compiler, telling it our closure takes an arbitrary object when in fact it must have an integer (or something that can be converted to an integer). If fact, we can now write code that is statically type valid, but fails at run time (with a class cast exception):
u("hello")
If our statically typed closures can’t lead to code that is runtime type-safe, then what is the advantage of bothering with static declarations. We might as well stay with the dynamically typed closures that offer the same amount of type safety and are much less complex. The Example Was Rigged!Well, maybe. The problem lies in trying to use statically typed closures with functions that take generic arguments. But isn’t that exactly the situation where static type safety is most needed? If statically declared closures can’t handle the hard problems, why bother with them on the easy ones? Can We Fix This?Perhaps. I believe it is possible to define statically typed closures. In fact, this article lays out how to do it in Eiffel (the agents described in the article are essentially closures). But the Eiffel language supports generics (and in particular generic Tuples) to work around the problems outlined here. Adding that to the language makes it even more complicated. SummaryAt first glance, statically typed generics look really attractive, but add a great deal of complexity without achieving static type safety for a very common class of problems where closures are commonly used. I just don’t see the advantage. Mike Spille says "On typing, it’s a double-edged sword if you’re coming from a Java perspective.", and he is right. And you really have to be careful not to cut yourself on that sword. comments | ||
| Pennsylvania Dutch | 20 Jan 05 | |
| [ print link all ] | ||
Eckel on RubyRecently Bruce Eckel addresses the "Ruby Issue" yet again. Evidently a number of years ago Bruce brushed off Ruby based on a quick perusual of a Ruby book. Ever since then, the Ruby community has been trying to convert him, finding it hard to believe that someone as intelligent and well spoken as Bruce didn’t immediately fall in love with our little language.In the article, he says:
Well that explains everything! You see, my father was Amish (until he was about 13 years old) and my mother’s parents were Amish. The Amish speak Pennsylvania Dutch (a distant dialect of German) in their homes and use High German in their church services. Often Amish children will enter first grade before they learn to speak english. So I grew up in a community where Pennsylvania Dutch was often spoken, and influenced the way english was spoken. This "backwards" way of speaking sounds very familiar to me. No wonder I am so attracted to the Ruby language. An AsideI do find it humorous that Bruce is (mildly) poking fun at the Ruby (and Perl) technique of using if and unless as statement modifiers. Bruce makes it sound as if putting the if condition at the end of a statement (e.g. return if data.nil?) is somehow awkward english. Now go reread the first two sentences of the paragraph that begins "This makes sense if …". Interesting. Coming Around?Actually, from the tone of the article (and some of the later comments), I get the feeling that Bruce respects that fact that a lot of people find Ruby attractive and productive. Its just that it doesn’t click for him. That’s OK. As my Amish relatives would say, "It takes all kinds, the world to make". Increase Your Ruby SkillsIf you really want to increase your Ruby skills, I recommend that you spend a good part of the day listening to John Schmid sing a few Amish folk songs. My favorite is "Maydly vit du hayra?" where the Amish father queries his young daughter on the type of man she wants to marry. I actually remember the song "Reide, Reide, Geile" (Ride, Ride the Horse) sung in my house while growing up (usually as we were bouncing on Dad’s leg). Good Stuff! comments | ||
| Web Applications | 20 Jan 05 | |
| [ print link all ] | ||
|
I am really suprised at the number of web applications that I have started
using in just the past few months. I’ve never been a fan of web apps
(too slow, clusmy interfaces, etc.), but GMail broke the mold here and
showed the world what a good web interface could do. And I think we will
see more of that as time goes on.
Anyways, here’s what I use…
comments | ||
| Ron Jeffries is Looking ... | 20 Jan 05 | |
| [ print link all ] | ||
|
It seems that Ron Jeffries is looking for a little help on his web site.
One of the desirable skills listed is Ruby. He’s not promising to pay
much, but hey, you get to use Ruby.
See www.xprogramming.com/Blog/Page.aspx?display=LittleHelp for details. comments | ||
| XP Cincy Makes a Surprise Move | 17 Jan 05 | |
| [ print link all ] | ||
It is funny how surprises happen when you least expect them.
XP in CincinnatiThe Cincinnati XP Users group meets on the first tuesday of every month. At the meetings we "practice" our XP skills by pairing and working a small web project for Childrens Hospital. The project is a simple scheduler for reserving rooms. Most of the meetings we have about 4 or 5 pairs of java programmers and one pair of Ruby programmers (the Ruby pair is usually me and Chris). Working on the project for only a few hours a month means that very little gets done at the meeting, but that’s ok because the meeting is more about learning the process that getting software delivered. But working on the same project for over a year is getting a bit old, and the group was looking for something new to work on. The January MeetingI didn’t make the January meeting, so I only got this news second hand. Here is a portion of the meeting summary that Mark Windholtz published. As you read this, keep in mind that the group has been exposed to Ruby over the past year, but only a couple of them had actually paired with me and had direct exposure to the language.
If you have not seen the Ruby on Rails 10 minute demo movie, it is worth downloading and watching. Really, it is only 10 minutes (not counting download time). Continuing with Mark’s summary.…
Skipping over some discussion stuff …
I think its going to be fun too. I can’t wait until the next meeting. That’s a big part of the Ruby attraction. It puts the fun back in programming. InvitationIf you are interested in Ruby, either a beginner or an expert, feel free to drop by the next Cincy-XP Users Group meeting on February 1. See www.objectwind.com/cgi-bin/wiki.cgi?MeetingTimeAndLocation if you need help finding us. comments | ||
| Slowing Down Calculations | 08 Dec 04 | |
| [ print link all ] | ||
Normally you want your calculations to go as fast as possible. But not
this time. Here we will look at how to slow them down. Slow them waaay
down.
Time for Some FunIf you are following the Ruby mailing list, you will see we just made a new release of RubyGems. For the past week, most of my spare time has gone into making that happen. Now its time to get back into some other projects that I’m woefully behind on … But before we do, it’s time to have a little fun with Ruby. A Language Based SpreadSheetPatrick Logan wonders aloud why spread sheets haven’t made it into programming languages as first class objects. He then goes on to speculate what it might look like in Smalltalk. And along the way, he bumps into some interesting concepts about evaluating expressions. Translating Patrick’s Smalltalk code into Ruby turns out to be quite straight forward … ss = SpreadSheet.new ss[1,1].value = 5 ss[1,2].value = ss[1,1] * 6 ss[1,3].value = ss[1,2] * 7 puts ss[1,3].value # => 210 ss is our spread sheet object. Indexing it with row and column indicies yields cells, which can hold formulas. The first cell gets a five. The second cell (at [1,,2]) gets 6 times that (30), and the final cell gets 7 times that (210). Straight forward arithmetic, right? Wrong! Remember that this is a spread sheet. Changing the values in cells should effect cells that derive from it. In other words, if we change the value of ss[1,1] and then ask for the value of ss[1,3], we should get a new value. ss[1,1].value = 10 puts ss[1,3].value # Should now print 420! The naive implementation of just storing values in arrays as we calculate them just isn’t going to hack it. Ummm … Why Don’t We Use Lambdas?My first thought was that we would want to just wrap the expressions in a lambda. Putting them in a lambda has the effect of deferring the evaluation of the expression until we really want it. And we can reevaluate the expression as needed as its dependents change. The result would look like this …
ss = SpreadSheet.new
ss[1,1].value = 5
ss[1,2].value = lambda { ss[1,1] * 6 }
ss[1,3].value = lambda { ss[1,2] * 7 }
puts ss[1,3].value # => 210
In fact, a commenter to Patrick’s blog suggested the same thing. Patrick responds.
Deferring Expressions in RubyHow would this work out in Ruby? In Ruby, all computation is accomplished by sending messages. To defer a computation, just capture its message and replay it later at your convenience. We will start with a formula object that turns any message sent to it into a deferred object.
class Formula < Builder::BlankSlate
def method_missing(sym, *args, &block)
Deferred.new(self, sym, args, block)
end
end
Since you generally want every message sent to a formula object to be recorded, I based Formula on the BlankSlate class I’ve mentioned earlier. Deferred is also fairly straight forward to write. The initialize method just records the receiver of a message, the message name, arguments and any blocks.
class Deferred < Formula
def initialize(target, operation, args, block)
@target = target
@operation = operation
@args = args
@block = block
end
# ...
We derive Deferred from Formula because we want operations against a deferred object to also be deferred, and Formula handles that perfectly. Now, when we want the value of a deferred operation, we need to ask it nicely. We will use a method named formula_value for that purpose.
def formula_value
@target.formula_value.send(@operation, *eval_args, &@block)
end
# ...
To replay the deferred operation, we need to get the target (reciever) of the message. Since the target was a formula, we need to ask for its formula value. We then send it the original operation (message name) and a list of arguments. Just one subtle note about the arguments. They too might (or might not) be formula objects, in which case we need to evaluate them before passing them to send. eval_args just creates a new list of formula values from the original argument list.
def eval_args
@args.collect { |a| a.formula_value }
end
end # of class Deferred
Formulas in ActionSuppose I had a Formula object, and tried to add 1 to it. What would I get … result = some_formula + 1 result is a new deferred object, capturing the sending of +1 to the formula. To get the real value, we ask the result for its formula_value: result.formula_value which recursively gets the formula value of some_formula and sends it a +1 message. Something is MissingGreat. We see how to get deferred evaluations if we have a formula object, but where does that original formula object come from? There are several options. One is to create a Formula wrapper around a normal Ruby value.
class Const < Formula
attr_reader :formula_value
def initialize(value)
@formula_value = value
end
end
Now we can say: result = Const.new(5) + 3 # Returns a deferred formula object and later ask: result.formula_value # Returns 8 Mirror, MirrorAnother question: I can see how formula+1 works. The + message is sent to a formula object and gets handled specially. But what if we write: 1 + formula Won’t 1 get confused because it doesn’t know how to handle a formula object? Well, yes and no. The + operation in Integer will get confused, but it has a backup procedure to follow when it doesn’t know how to add itself to an arbitrary object: It asks the object how to do it. Integer + will call coerce on the Formula object and expect Formula to figure out how to do the addition. Coerce should return a two element list whose elements can be added together. Here is coerce for Formula:
class Formula
def coerce(other)
[Const.new(other), self]
end
end
Formula just wraps the original number in a Formula wrapper and then lets the wrapper handle deferring the addition. The SpreadSheet CellsThe Cells of the spreadsheet are Formula objects too. The only catch here is that they can hold different Formula objects over time. value should calculate the value of a cell (and will in turn call formula_value to do so). value=(val) should set the internal formula to whatever the user specifies. Here is Cell in all its glory.
class Cell < Formula
def initialize
@formula = 0
end
def value
@formula.formula_value
end
def value=(new_value)
@formula = new_value
end
def formula_value
@formula.formula_value
end
end
Making a Cell object a formula is pretty key to the whole deferred calculation design. If a cell contains only normal Ruby objects, then its value can be calculated immediately. However, we want to defer calculations that depend upon other cells, and since adding a cell object to any expression will automatically defer it, we get the effect we want automatically. Hey! Wait a Minute!The astute observer will note that I initialize @formula in Cell to 0, but later in the code send a formula_value message to @formula. Won’t this cause problem, sending formula message to a non-formula object? Well, yes it would. But it simplifies the code greatly if we just pretend all objects are formulas and can respond to formula_value. Non-formula objects just respond by returning themselves. This is easy to accomplish.
module Kernel
def formula_value
self
end
end
(And this is why I chose a rather awkward name for fetching a formula’s value. Since all objects will implement this method, I wanted it to avoid potential name conflicts). The SpreadSheetThe final piece of the puzzle is the actual spread sheet object. Its only real function is to act as a lookup container for the Cell objects. My implementation uses a cheesy "convert two integers to a string key" technique. It works ok, but it bothers me.
class SpreadSheet
def initialize
@hash = Hash.new
end
def [](r,c)
@hash["#{r}@#{c}"] ||= Cell.new
end
end
That’s it. The guts of a spread sheet in under 100 lines of code. You can see the complete listing on my wiki. Other possibilitiesThis technique of deferring calculations has some really interesting possibilities. Imagine that instead of replaying deferred calculations, we examined the deferred expression and performed some operation on them. Like what? Well, maybe optimizing the expression, maybe analyzing the variable references, maybe generating SQL from them. Remember the Criteria library … it uses this technique to translate ruby code into SQL conditions. LimitationsBe careful with this technique. Although quite powerful, there are a couple of places that can cause problems. In particular, the && and || operators in Ruby are difficult to capture in this way. comments | ||
| Geek Birthday Humor | 20 Nov 04 | |
| [ print link all ] | ||
I’ve had a lot of fun with my birthday this year. I tell people that
…
Then I pause and let them do a double take at the graying color of my hair, and then finish with …
The joke goes over pretty well amongst my geek and programmer friends. However, when used in non-geek company, they just look at me as if I lost my mind. Perhaps I have. comments | ||
| Ruby Poetry | 18 Nov 04 | |
| [ print link all ] | ||
Robert Cottrell has captured the essence
of Ruby in haiku form:
These are almost the exact words of one of my coworkers, who after considering Java for a particular problem, decided to use Ruby instead. He said he just started writing a little bit of code and all of a sudden he realized that he was done. comments | ||
| Dependency Injection Revisited | 29 Oct 04 | |
| [ print link all ] | ||
|
In a blog
entry, Jamis Buck points out that Needle (a dependency injection framework
based on some of my random
thoughts) is a superset of the Service Locator pattern.
This is true in general. Both the DI and SL patterns provide containers that you pull objects out of. However, the essential difference between them is that your application code is aware of the Service Locator pattern, but Dependency Injection is invisible to the app. So, if you take your DI container and pass it to a constructor, you are really using the DI container in a Service Locator manner. The key question to ask is: If you were to change the interface to the DI container, does your app need to change as well. Someone else asked me how to decide between DI and SL, or just rolling your own. My answer is to look at the amount of pain you suffer on configuring your the modules[1] of your system. Ruby is flexible enough so that most projects can get by without either DI or SL. When it begins to get cumbersome managing different configurations by hand, it is fairly painless to switch to lightweight DI container such as Needle.
comments | ||
| Creativity in Pairs | 27 Oct 04 | |
| [ print link all ] | ||
Ralph Johnson writes
about creativity being a cooporative effort rather than a solitary
endeavor.
I certainly experienced that in several different ways over the last few weeks. The first example was my exploration into Ruby-based dependency injection. It was sparked by Jamis Buck’s presentation on Copland at RubyConf2004. I wrote up some ideas and Jamis took those bare ideas and fleshed them out into a real product (Needle) which represents the lightweight view of Dependency Injection. Evind Eklund also made some suggestions for improvements and the final result is something better that any of us would have come up with in isolation. Another example happened this past month in the weeks after RubyConf. David Heinemeier Hansson has decided to include support for my XML Builder object in Rails. He mentioned to me that support for the processing instructions and declarations would be nice. I threw something together, but got some of the details wrong. Later that evening Rich Kilmer pops up an IM window and together we work out the rough spots in the design. Along the way, we come up with a cool way of supporting namespaces that fits well with the Builder style. It was a great session with each of us contributing and feeding off the ideas of the other. I think Extreme Programming’s emphasis of pair programming is an attempt to tap into the creative potential of two different minds attacking a problem from different viewpoints. And it works fairly well at that. Now I’m wondering what other activities might benefit from the "two heads are better than one" approach. Maybe I’ll grab a friend and we will think about it together. comments | ||
