All, I tend to agree with Devon & Giles, in that using the standard APL character set for J is not a very good idea. For one thing, a primitive in J may often have subtly different functionality than the a similar primitive in APL, which could cause considerable confusion for those using both languages. Plus there are many functions in J that have no exact equivalent in APL, and vice-versa.
>From what I understand, the APL symbols were removed from J primarily because of the difficulty of creating editors and keyboards for those special characters, as well as the difficulty of providing universally-available mechanisms to enter and display the symbols on any platform. So with J, Iverson and Hui sacrificed the ultimate elegance of a single-symbol-per-primitive language for the practicality of cross-platform support. Along the way, they fixed various problems wih APL's syntax, and made overall improvements improved the language, which offset by far, the loss in elegance of the single-symbol representation. Today, with the advent of modern touchscreens, soft keyboards, and graphics displays, developing a cross-platform programming language that uses graphical symbols instead of ASCII characters would be a much less daunting task. Not a simple task by any means, but a feasible one. The rationale for this bold step would boil down to one main issue: What advantages would a single-symbol-per function representation have, if any, over current multi-character ASCII-based languages such as J. I see a couple of advantages to a single-symbol representation: 1. J's syntax relies on the period, colon, and semi-colon as modifiers, to alter the functionality of many primitives. While this is handy to type on an ASCII keyboard, the display of modified primitives can be hard to read, since the modifiers rely on the viewing of single dots, which can be quite small. Also when hand-writing J, the periods and colons can easily get lost in the mix. If we want J to be a general mathematics language, relying on tiny dots to help define formulas can be dangerous. 2. Using ASCII characters for verb symbols is handy for typing on a standard ASCII keyboard. However, overloading the meanings of the already-overloaded ASCII character set is just asking for trouble in a programming language. J's reliance on spaces to separate certain parse objects works well, but spaces can be a problem in hand-written formulas. A slight gap in a formula or variable name can cause a drastic miscommunication. I believe that Ken Iverson originally designed APL to be a general-purpose mathematical notation. Only later was APL made executable on a computer, as an interesting exercise. A notation must be able to be hand-written clearly, as well as printed. Iverson knew that single-symbol primitives would provide the most elegant solution to this requirement. Primitive symbols allowed the standard ASCII characters to be reserved for variable names and defined functions, thus improving readability. J's 1-2 ASCII character primitives were a pragmatic compromise to this elegant purity, given early hardware limitations. . The key here is the concept of a single-graphical-symbol representation for every language primitive, which APL came close to acheving. Nothing says however, that the symbols have to be APL symbols. In fact, it probably would be a good idea to purposely NOT use APL's exact symbols in a new single-symbol language, unless perhaps the underlying functionality for a primitive matched an APL primitive exactly. Ideally, the graphical symbol for a particular primitive would indicate the operation that it performs in some concise way. If a symbol could somehow hint at its functionality in the design of the symbol, that would provide a handy mnemonic for less-experienced programmers. If we wanted to get really creative, we could even design animated graphic symbols which demonstrate the functions performed by each primitive verb. An abbreviated version of the animations in the NuVoc vocabulary at http://www.jsoftware.com/jwiki/Vocabulary/ gives some idea of what could be done. Animated symbols might be overkill, but a tool-tip that pops-up with a short explanation of the function when one hovers the mouse over a symbol, could be a great help for lowering the learning curve. Also, providing a right-click context menu for every symbol would be a great learning/reminding tool. The context menu would provide links to the formal vocabulary, to NuVoc for the newbies, and perhaps a link to a dictionary section on the primitive as well. There are a large number of primitive symbols in a language like APL or J, and remembering the functionality of a specific symbol can be a daunting task for even more experienced users. Utilizing modern graphics and web technologies to provide cross-platform symbol display and entry, along with tool-tips and hyperlinked context menus for symbols, could significantly lower the learning curve and improve coding efficiency for all users. The biggest hurdle that any pure symbolic programming language must overcome, is the data entry problem. Modern keyboards only have 40-some useable symbol keys, and symbolic languages like J or APL have at least 120-some primitives, so there is a basic problem. Also, modern keyboards all typically have some language variant of ASCII labels on each key. This makes selecting the right key to press in order to generate a specific symbol a memorization nightmare. Iverson cleverly circumvented this issue by using multiple ASCII characters to represent most primitives, thus making the key labels and the code representation match.. An obvious data entry method for single-graphic symbols would be to simply keep the 1-2 ASCII character approach for entering primitives, and have a display-mode switch that would switch between the ASCII representation and the graphical symbols. The ASCII representation of the primitives could be used as a kind of typographical system like Knuth's TeX language, which is used for typesetting mathematical expressions. This doesn't really solve the memorization challenge, as trying to memorize which key sequence generates the graphic symbol you wanted is still a problem. However this data-entry problem is not unique to APL-like symbolic languages. Symbolic languages like Chinese (Mandarin) and Japanese, have literally thousands of symbols that must be written to express the full language. Special complex, multi-layered keyboards are used to enter all of these symbols, to write in those languages. Even then, one had to remember which keyboard mode contained the specific symbol. Luckily, there is another, more radical approach which solves the keyboard memorization problem, the TeX meta-language issue, the dual-display-mode issue, and the keyboard label problem, all in one step. The advent of modern handwriting recognition systems has opened up a new option for general symbol entry. Google recently released Handwrite<http://googleblog.blogspot.tw/2012/07/make-your-mark-on-google-with-handwrite.html>, a new feature for mobile phones and tablets that allows users to hand-write symbols directly on a browser window without opening a keyboard – and it supports Chinese! I have a Galaxy Note II with the built-in pen, and Handwrite works great on that device. My native Taiwanese friend can input the thousands of Mandarin symbols almost as fast as she can talk. The various mobile platform app stores have many variations of this type of app. You don't have to remember where a symbol resides on a keyboard. You just DRAW the exact symbols you want on the screen, and the symbol shows up in your workspace. The input problem is solved. No dual-mode display is needed. We now have the capability to create a single-symbol-per-primitive language that can be easily entered on any touchscreen. Keyboard entry could still use the multi-ASCII-character-per-symbol entry method, but that would be slowly obsoleted. Entering single-symbol primitives would require nothing more than drawing the symbol on a touch-screen. We could finally get back to Iverson's original idea of a mathematical *notation*, which can be easily and clearly hand-written, as well as executed. The J language is a beautiful compromise, but we don't need to compromise any longer. Skip -- Skip Cave Cave Consulting LLC ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
