Postscript Syntax Highlighting

In this blog post I will outline the GtkSourceView language definition for Postscript.

Postscript is best know as a page description language. I found myself using it to produce a set of pictures, but was disappointed that no syntax highlighting was available. Luckily I had prior experience

Just like the the blog post about MAGMA syntax highlighting I used GtkSourceView to create a language definition file for Postscript. The language definition file can be found on github. For instructions about installing the language definition file I refer to the post about MAGMA. (Or you can find instructions in the README file.)

Have fun with Postscript!

MAGMA Syntax Highlighting

This blog post points out how to add syntax highlighting for MAGMA in gedit.

MAGMA is a very good computer algebra system, but not very well known outside a select mathematical circle. So it is not very surprising that gedit does not know how to syntax highlight MAGMA code out of the box.

Gedit uses GtkSourceView as its syntax highlighting engine. GtkSourceView can be extended by providing a language definition file.

So I set out to create a language definition file for MAGMA. The results can be found at github. In order to use is, you have to place the magma.lang file in the following directory:

~/.local/share/gtksourceview-2.0/language-specs

Below you can find a screenshot of a snippet of MAGMA code highlighted by gedit.

Pitfalls of Reflection

In this post I will discuss a pitfall of the use of reflection in Java. Specifically how reflection can obscure and even change the semantics of a piece of code.

What is wrong with the following example of JavaBean naming convention?

public Boolean isCorrect() {
    /* implementation not shown. */
}

Did you spot the capital B on the Boolean return type? According to the JavaBean naming convention the property does not fall under the special rules for booleans and should be named accordingly.

public Boolean getCorrect() {
    /* implementation not shown. */
}

Although there is a sleight syntactic difference, the apparent semantic difference is non-existent. According to William Shakespeare:

A rose by any other name would smell as sweet

Enter reflection. By using reflection it is possible to perform hugely different behaviour depending on the name of a method. The following whimsical example is a clear demonstration of this fact.

Class aClass = ReflectedClass.class;
Method method;
try
{
    method = aClass.getDeclaredMethod("isCorrect");
    protect(Planet.EARTH);
}
catch (NoSuchMethodException e)
{
    destroy(Planet.EARTH);
}

So one of the pitfalls of reflection is the hidden semantics associated with code. Stated in other words: the influence of code can not be inferred by the syntactic definition of that code.