Visual J Interface (2)

A second take:

1) Types are represented by colours (Nouns: grey, Verbs: yellow, Adverbs: blue, Conjunctions: red). Derived entities are nested, the colour of the outermost box is the type of the derived entity. Using a blend of colours is impractical because of the large number of derived entities. Panels 1 and 2 in the first diagram use shapes in addition to colours to represent the types.

2) Hooks and forks have distinct colours, they are expanded to explicit conjunctions. When clicked the display of hooks and forks could be expanded further to the restructuring of their function arguments, this behaviour could be extended to all conjunctions.

3) Some ideas on visualising execution. A part of the structure may be highlighted and interactively executed(changing the structure as functions are applied) or the whole function may be executed step-by-step. Incomplete.

  

Visual J Interface

Reading the J general mailing list I came across a post by Bob Therriault on ideas for a visual J interface. I found his ideas very promising, he evolved the simple J tree display into something more user-friendly and informative.

Building on Therriault's ideas, I have sketched out some ideas I would like in a J visual interface.

1) A Derived entity should take a colour which is a mixture of the colours of its parts. This allows us to quickly identify how it was formed. Restricting verbs, conjunctions and nouns to primary colours makes this easier.

2) Hooks and forks should have distinct colours as they are special constructs in the language.

3) Gerunds should be shaded a common colour(close to a verb's colour preferably) to emphasize that it acts as one element.

4) The arguments to a function (x and y) should be optionally displayed(toggled or and off).

5) The user should be allowed to edit the structure by dragging and dropping elements as they wish and have the code updated automatically.

Some more ideas are detailed in the diagrams below:

 

An alternate version where all arrows point up, indicating data being fed into a pipeline. Expansions of derived entities are represented by dashed lines. This way the figure can be flipped upside down and still be readable.

Left-Leaning Bidents

Forks in J, previously discussed here, have a very useful extension when the left element is a noun.

Normally, a fork(also known as a trident) is an isolated series of 3 functions(functions placed one after the other, known as a train), when arranged in this manner they have an invisible combinator applied to them such that if f, g and h are functions and x, y are arguments:

      (f g h) y = f(y) g h(y)
    x (f g h) y = (x f(y)) g (x h(y))

A hook(bident) is an isolated series of 2 functions, this also has an invisible combinator applied to it, such that if f and g are functions and x,y are arguments:

      (g h) y = y g h(y)
    x (g h) y = x g h y

The motivation for using such constructs:

1) It eliminates explicit variables, a lot of useful expressions can be simply written as a series of functions which are converted into hooks and forks by the above mechanism.

    mean=: +/ % #

2) A series of functions can now have dyadic functions embedded inside it(e.g. the central element of a fork). This allows us to use infix functions naturally and frees us from the limitations of a composition-only function application style, a limitation such as being unable to use infix functions in a series of functions without declaring explicit variables. This added expressibility is the reason for 1).

3) It gives utility to otherwise useless but syntactically valid expressions(with minimal additions to the parser). An isolated odd number of functions arranged in a series becomes a fork, an even number of functions becomes a hook.

    diff =: - +/ % #
    diff2=: - mean
    (diff i.5) = diff2 i.5  NB. Equivalent
1
    (diff = diff2) i.5      NB. A fork equivalent to the above
1

If the left element of a fork is a noun, then the fork behaves differently, the left noun is used as a left argument to the dyadic function g(the central element of the fork):

       (n g h) y = n g h(y)
     x (n g h) y = n g (x h(y))

This is equivalent to currying g using n and is often used in the same manner, for example the expression 3n+1 can be written as a fork using this extension:

    1+3*]

The special behaviour exhibited by forks with a left noun element is termed a "Left-leaning fork".

I would like to see a similar extension applied to hooks, a "Left-leaning hook", for the case of a noun followed by a verb. This was inspired by Nial which has a similar syntax for currying. Hooks can then be used to directly curry, no longer needing the conjunction &(bond).

      (n g) y = n g y
    x (n g) y = n g y

For example:

    f1     =: (3*)`(_5+~)@.*
    collatz=: -:`(1+3*])@.(2|)
    f2     =: 3 (4 : 'x%+:>:x+y')   NB. Explicit definition curry

The motivation for this:

1) It simplifies code. No longer needing explicit currying achieved using a conjunction, the purity of hooks and forks is maintained. This is analogous to how cap([:) gives forks the ability to perform function composition, in the same vein we are able to extend hooks to perform currying.

2) It is a logical extension to a currently unused syntactic expression.

    (2+) = (2+])

The implementation of this extension is trivial; the hook will simply check the first element's type, if it is a noun, a left-leaning hook is called in the manner specified above. The current parse table doesn't need to be changed because the line matching hooks already allows nouns on the left side. I have experimented with this in the old j7 source code.