Mohsen Vakilian's Blog

March 16, 2008

Jackpot Rule Language

Filed under: evolution,refactoring,technology — mohsenvakilian @ 3:18 pm

Jackpot is a NetBeans module that lets you define custom transformations. Jackpot transformations can be specified in two ways:

  1. Using Jackpot rules matching program segments or
  2. Using Jackpot API to manipulate the AST.

The Jackpot API is still under development. The rule language has been designed by James Gosling. And, in the following we’re going to know more about the Jackpot rule language by explaining two examples.

The first rule, removes all unnecessary casts. In this rule, meta-variables such as $T and $a are used to match various program elements. As you see in this example, type matching facilities are supported in Jackpot as guard expressions after the “::” operator.

($T)$a => $a :: $a instanceof $T;

The second rule transforms a regular for-loop into an enhanced for-loop. This rule uses both meta-lists and built-in guards. The $stmts$ symbol is a meta-list which matches a list of statements. The expression referencedIn($i, $stmts$), is a built-in guard which checks if the meta-variable $i has ever been referenced in the meta-list $stmts$.

for(int $i; $i < $array.length; i++) {
$T $var = ($T)$array[$i];
} =>
for($T $var : $array) {
} :: !referencedIn($i, $stmts$);

Jackpot rules are readable and if somebody needs a more sophisticated transformation he/she can use the Jackpot API to programmatically perform the transformation. Jackpot seems to be suitable for cases when you want to migrate your client code to use a new API. However, it lacks constructs to specify the scope. So, it may not be appropriate for transforming the library itself.
In Jackpot, no flow analysis is done during execution of a rule file. And, in an interview with Tom Ball, the Jackpot team leader, he mentions that Jackpot cannot be used outside of the NetBeans IDE.


March 12, 2008

Google Gears Code Lab

Filed under: technology — mohsenvakilian @ 6:32 pm

On March 3rd, Google held a three hour long code lab on Google Gears at UIUC. The workshop had two parts: the first part consisted of a nice high-level presentation of Google Gears, its uses, architectural concerns, …

And, the second part consisted of a presentation on how to actually use Google Gears in our own code. Unfortunately, I couldn’t get Google Gears installed on my Ubuntu to follow the tutorial. However, I got a good idea of how Google Gears is used by following the slides. Indeed, it was a good opportunity for me to experience Javascript hacks for a couple of hours!

June 18, 2007

Hierarchical Tagging

Filed under: technology — mohsenvakilian @ 1:11 pm

Do you usually tag your data (bookmarks, emails, …) with multiple labels?
Sometimes, it’s because of the different aspects of the contents.
However, there are cases where some labels are redundant as they all can be inferred from a single label.

An Example: When I was looking for some RSS reader applications, I used Google Bookmarks (which I call “GMark”) to bookmark the applications I found. I wanted to have distinct labels for web-based and rich client applications. So, I tagged them with the labels “Web.RSS Reader” and “Rich Client.RSS Reader”. But, this way, I won’t be able to get a list of all RSS reader applications by clicking a single label!

In the following, I will present two solutions I could think of:

Hierarchy of Labels for RSS Reader Applications

Solution 1: A Bookmarking application can allow creation of hierarchical labels. That is, creating a label like “Web.RSS Reader” which is inherited from another label named “RSS Reader”. This way, tagging an item by “Web.RSS Reader” will tag it implicitly by “RSS Reader”.

Solution 2: A Bookmarking application could let users make a query based on labels. That is, to ask for all items tagged with labels of the form “*.RSS Reader”.

Now, let’s compare these two solutions. There is a subtle point in the second solution and that is the careful use of dot notation in naming labels. This notation carries the concept of inheritance implicitly, doesn’t it?
I myself prefer the second solution because of its simplicity. Hierarchies, inheritance and abstractions are more complex concepts attractive to mathematically biased minds such as mine—the engineers’ minds! Therefore, I believe, it would be better to provide people with simple solutions though they might not be elegant from a mathematical point of view.
Although abstraction plays an important role in computer science, I believe it doesn’t have to play such a big role in our everyday lives. Anyway, I don’t want to talk philosophically. But, I might write about abstraction later!

Blog at