Essays/Teaching J Syntax

Topics

There are several aspects of J syntax which a person would not see in Java, or similar "traditional" computer programming language:

Rhematics

J's word forming rules are likely to be unfamiliar to a Java programmer. Unquoted tokens or words in Java never include spaces, for example. Also, Java's analogy to J's locales are dealt with syntactically in Java rather than using special word formation rules (with specialized 18!: functions) as in J. (Java doesn't have J's constant forms either, but perhaps that topic can be left alone for an algorithms class.) This is also an issue for understanding words like for_var.

Sentences

J sentences are terminated by the end of the line. (Or, in explicit definitions, by a control word or the end of the definition.) Java's equivalent ("statements") are terminated by a semi-colon, and in Java, end of line (outside of quotes and line comments) is no different from a space. This might seem like a simple issue but if it's not addressed explicitly a person might stumble over it.

Scripts

J's parser is capable of doing different kinds of things with different lines. The n : 0 convention (which is terminated by an isolated right parenthesis) is something Java programmers probably have never seen before. In Java this would be a syntactic issue, and it's probably best to treat this as a syntactic issue in J as well. (Though it's quite relevant that there's no rule in J's expression parser for this.)

High-level functions (adverbs, conjunctions)

Java doesn't have high level functions as such. To some degree their features can be emulated using methods which take objects of class Dyad or Monad (which would have to be user defined classes in Java). But even if this were done, the syntax of these methods in Java would be no different from the syntax of any other method.

Explicit vs. Tacit

Java doesn't have anything like J's tacit definitions, or J's immediate execution mode. So people might be surprised to find that keywords like if. or while. don't work outside of explicit definitions.

Trains (hooks, forks)

Again, Java doesn't have anything like this (though, again, the effects can be achieved in a more round-about fashion).

Copula

J's =: and =. are different from := in Java. In Java, there's other syntax to indicate the scope of a name (where you also declare the type of the variable), the innermost declaration determines whether Java's := is assigning a class/object variable (like =:) or a block scoped variable (like =.).

Furthermore, Java's := can never change the name class of a name. Java's := can only set one kind of name (the name of an object) and uses different syntax when using that object as a verb (methods) or when using that object as a noun (fields).

Ambivalence

Java doesn't allow user defined words with a left scope, and even right scope for user defined words is more constrained than for built-ins. So the distinction between Monad and Dyad would be unfamiliar to some Java programmers, as would the idea of defining such words.

Lack of declarations

In Java, syntax requires that the type of a name be uniquely identified. This is not the case in J where values are typed, rather than names. Also, J uses names like y, u, and m for arguments in explicit definitions, and these would be worth understanding if they're used in your class.

Semantics

Some of J's semantic properties (such as Rank, or the way that 18!:4 brings following lines in a script into a specific class or object) might seem like syntactic issues to people with a Java background.

More generally, J uses semantics to address issues which are syntactic issues in other languages, and a person not familiar with J would not know how to properly phrase questions about these issues using J jargon.

Approaches

If I had students saying they didn't understand J's syntax, I'd think it worth spending an hour or two of class time explaining it to them -- and drawing as many analogies as I could to other situations they might be familiar with (for example, notation that looks like fork is often used in math classes).

At the very least, I'd have handouts for them, outlining as much about these issues as they'd need to know for what I'm covering, and pointing at specifically useful documentation for people who want the details.

As a general rule: people who say they don't understand something learn quite a bit faster on that topic than people who say they do understand the topic. But it helps quite a bit when they know what the symbols stand for. (Even people interested in music need to know the notes before they can play the tune.)