An attempt at a visual J GUI inspired by Roger Stokes

Over the next series of blog posts I am going to explore some of the potential ways the J interface could reduce the cognitive load on the user. This is particularly important for novices, since lowering the barriers to understanding may increase the accessibility of the language. Since J uses such a terse form of expression, presenting the language accessibly and accurately involves concepts of both mathematics and user interface design. Enough of the preamble, let’s dig into the problem.

As an example sentence we’ll use a sentence with a conjunction, an adverb, a monad verb, a dyad verb, a fork and a hook

(– +/ % # ) 6 8 _4 3.5 4.2

This sentence, (the verb is contained within the brackets) subtracts the mean of the list from each value in the list. Moving from right to left, the list is the sequence of numbers, the # is a monadic verb returning the number of items in the list, the %  takes the result of +/ (the / adverb modifies + to insert + between each item in the list giving the sum of the list) and divides it by the number of items. The +/% # sequence is called a fork (a form of conjunction). This fork and the first ‘–’ create a hook in which the list becomes the left argument of ‘–’ with the right argument from the conjunction. Obviously, using English to describe this function is not an optimal solution. It is verbose compared with the J sentence and relies on the user’s background knowledge for understanding.

The question remains – can we do anything to present the original sentence in a way more accessible to users?

J itself provides some options that help. By selecting the boxed representation and isolating the operator we create a more hierarchical breakdown of the sentence, although  the number list must be removed to avoid evaluation.

(– +/ % # )

This reveals the structure by boxing the operators so that the first parsed are buried deepest in the structure. However, it does not show us how the operators interact with the number list. It also does not identify the parts of speech of the sentence, which can be helpful to understanding the program.

A further option is to load the ‘trace’ script which provides a verb ‘trace’ that will break down each step of the parsing process, showing the parsing rule as a heading, followed by the left argument, operator, right argument and result. This allows us to see the structure by revealing the steps that build it; culminating in the final result.

trace ‘(- +/ % # ) 6 8 _4 3.5 4.2’

————— 3 Adverb —–




————— 5 Trident —-




+/ % #

————— 6 Bident —–

+/ % #

– (+/ % #)

————— 8 Paren ——


– (+/ % #)


– (+/ % #)

————— 0 Monad ——

– (+/ % #)

6 8 _4 3.5 4.2

2.46 4.46 _7.54 _0.04 0.66


2.46 4.46 _7.54 _0.04 0.66

Unfortunately, the result of this analysis gives us the result by applying the monad – (+/ % #) to the list, without explaining how the result is obtained. This is a lot of work to ask of someone learning the language. It would be useful if the program could follow the path of the argument as it is processed by each component of the verb, even though the actual processing of the language does not necessarily follow the same process, the results are identical and the ‘human’ form is more accessible.

The function diagrams of Roger Stokes in ‘Learning J’ provide an inspiration for this approach, and we can begin to see how the arguments apply to the operators.

Given that (f g) y       means   y f (g y)

This illustration helps explain the monadic fork, which in our example is the ‘– (+/ % #)’ combination ( f being – and g being (+/ % #) ). The nice thing about this diagram is that it for the first time shows the way the operators interact with the arguments. Funnily enough it uses ‘black boxes’ to reveal what’s going on inside the ‘black box’. If we take a similar diagram for monadic forks:

where (f g h) y     means   (f y) g (h y)

Then combine them so that the g in monadic hook becomes the entire diagram for monadic fork,

and finally substitute our program, (- +/ % # ), into the resulting diagram, this is what we could get:

Prettying it up a bit with Keynote we get:

There are a few problems with the illustration above, such as the fact that the +/ should be further broken down to its constituent + and /, and the hook is identified as a modified J whereas a better representation of a hook could be found; but for now this gives some ideas about the approach  in developing a more visual approach to J.

My next post will include a bit of video to simulate the interaction of a user with a simplified diagram similar to the one above.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s