Defining the UI

The main feature we want for the rewriting tool UI it’s to be example driven. Two very similar examples:

Option 1 – All in the same view


Option 2 – A tabed view



Option 3 – A 3-Column layout

Screenshot from 2013-06-14 21:57:42

We also want to be possible:

  • select a method and drop into the example text editor.
  • manipulate the ASTs nodes in the text editor to make simple define transformations and matching.
  • highlight the matched parts from the example.
  • select scopes to apply the rule.
  • preview the changes.
  • show the transformation in the example expression.
  • modify an expression throw the example or writing the pattern.
  • output the smalltalk valid code that produces the effect we see in the example.

Next steps…

Now we have a very powerful tool but quite complex to use… The pattern’s definitions ends up been confusing and lot of people dismiss the tool for this.

The fact that the patterns are strings is one of the causes in misunderstanding and encourage to produce lot of mistakes, when we want to match an expression thinking in a method definition we think in terms of: a method contains this statement, or declares this variable and not in complex regular expressions, it’s also true that sometimes we end up with a cryptic expression, hard to understand by others (even for ourselves).

It would be great to have a very expressive api for what we want to do, for example make possible to say something similar to:

“some scope” pattern
includesStatement: anStatement;
hasTemporaryVariable: aVariable.

We should write some nice examples of usage and also take a look into the rewriting engine, we could do lot of improvements.

All of this sounds very ambitious, so I will start for defining an UI for make the patterns auto generated in an easy way with lot of cool features, specially example driven when building expressions.

Once we have the UI and a nice video showing how to use it… we can improve the API and make it more expressive and if we have time we will take a look in the rewrite engine… but first let’s do these easy to use!

A look into the rewrite tool

Trying to catch up with the current status in the rewrite tool my mentors suggested me to look into The Rewrite Tool, specially in a presentation from John Brant and Don Roberts.

I will write a short summary of what I read and then some conclusions about it.

The grammar of a method definition
The ultimate goal is to transform the code we have written, so we are going to focus in a method definition.
It’s very simple: we have the method name and a sequence of statements.
The method name can be unary, binary or keyword and the sequence node it’s conformed by temporary variables declaration (optional) and statements.

Representing the method definition
In the current implementation of Pharo we have an AST implemented that is very usefull for what we want to achive.
An AST or Abstract Syntax Tree is a tree representation of the syntax of an expresion.
So I will explain the main points in the representation of a method.
We have a MethodNode that contains (mainly) arguments, the selector (as the selector parts) and a body. Inside the body we have a SequenceNode that contains (mainly) the temporaries variables and a collection of statements. The statements can be any kind: AssigmentNode, ReturnNode, etc.
Its easier to inderstand with an example, if we have this method definition:

selector: arg1 and: arg2
|temp1 temp2|

temp1 := OrderedCollection new.
temp2 := arg1, arg2.
^temp1 + temp2

The AST will look like:

Matching an expression
For matching the tool provides the possibility to indicate a pattern, and the ability to specify throw symbols different meta variables for matching.

The real power of the tool is the number of variants that admit, making it really flexible.


Also exists the possibility to use another pattern for matching: {:node | <condition>} the node is a method node and the condition it’s valid Smalltalk code.

Some thoughts

  • In order to win flexibility, the patterns seems quite complex to write from scratch.
  • The real power for matching derives in the combination of symbols, but as the patterns are represented by strings it seems quite confusing.
  • Many times it’s easier to think in examples before writing the pattern.