As I go through this discussion, I think I have gotten over my dislike of using the APL character set to replace many, if not most of the 1-2 ASCII character symbols for J primitives. Ken did much too good a job of designing the APL glyphs, and each APL glyph does a great job of hinting at its specific primitive function. Functionally-related primitives in APL are graphically related as well. We might as well take advantage of the similarities between many of the J primitives and the APL primitives
In most cases it would be difficult to come up with better glyphs for a single-glyph J representation than what Ken designed for APL over 50 years ago. It is clear that there will be some new glyphs to design, to fit J primitives that don't have close relatives in APL. But in many cases we can pretty much replace a J 1-2 ASCII glyph primitive with its equivalent APL single glyph. And of course there are several glyphs that are the same (+ - _ etc.) This certainly simplifies the problem of how to come up with a new single-glyph character set to represent the J primitives. We can just use the unicode APL character font for the new J representation, with a few new glyphs for the J primitives that don't fit with APL (@ @. etc). Note that I am not proposing we change J's functionality in any way. I just propose changing the printed or displayed representation of the J primitives. But now we have to look at the basic issue of how to input a single-glyph representation of the J language. We would like to avoid requiring keyboard stickers, overstrikes, or obscure ASCII key sequences to produce the APL glyphs. To keep the cognitive load down, we would like whatever the user has to remember in order to input a glyph, to be as close as possible to the glyph itself. William had issues with a pure APL-character representation of J because of the purported difficulty of entering the APL glyphs from the keyboard. He rightly saw the issue as a tradeoff between the purity of the single-glyph representation, and the mismatch between what one has to remember to input, and what gets displayed. However I think there is a way, or likely more than one way, that we can have all of the advantages of an all-single glyph primitive set, and have several pragmatic and perhaps even elegant options of how one could input a single-glyph representation of J. Lets look at some different scenarios for the input of a single-glyph J language: 1, You are an experienced J programmer. You have memorized most, if not all of the key sequences for J primitives. For this scenario, the input mechanism should allow you to type the 1-2 ASCII character sequences for the J primitive, and the new APL-like single glyph symbol will appear on the screen. This isn't optimum, because the keyed input seems to have no connection to the screen display, That is unless you already know the connection between ASCII-J and the APL glyphs, which can be a significant memorization issue. However, for veteran J programmers who have memorized J's primitive key sequences, this could be the best option. 2, You are a J user, but by no means an expert. You can remember some of J's 1-2 character ASCII primitives, and perhaps the names of some primitives. So you begin to type the ASCII character sequence for the J primitive, or perhaps the text name of the J primitive. Up on the auto-complete bar, the possible single-glyph APL symbols start appearing. When you see the symbol you want, you just select that symbol, and you are done. In many cases, you will only have to type one or two characters, to get the symbol you want in the auto-compete bar. This approach could work even for veteran J programmers, who don't always remember the key sequence for a specific J primitive, but can remember the primitive name, or vice-versa. 3. You are a newbie, and you have not learned any of the 1-2 character J primitives. In fact, the Dictionary and Vocabulary that is presented to you will show the single-glyph APL symbols, not any of the ASCII J sequences. In this case it will be assumed that you have no idea about the current 2-character J primitives, and you should not need to know them. There are many ways to deal with this scenario. Here are a few: 3a. In this scenario the user just needs to memorize the names of the J primitives. Then when the user begins to type the text name of the required glyph using the ASCII keyboard (rho, iota, drop, grade up, etc.- we could use APL names or J names), the possible single-glyph symbols will appear in the auto-compete bar. The user can then select the appropriate symbol from the auto-complete bar. In some cases (plus, minus, etc) no auto-compete step is needed. This approach keeps a close connection between the glyph name and the glyph itself - a reasonable way to avoid a complex memorization task. One might want to let the saltire and obelus be represented by a lower-case "x" and the percent sign on the ASCII keyboard respectively, though that is starting to move away from the requirement for a "close match" between what is entered and what is displayed. 3b. In this scenario the user only memorizes the actual single-glyph symbols. The user will see a subset of the APL symbols on a soft keyboard. Each key has a glyph that is one of a group of related glyphs (equal/not-equal, grade up/down, take/drop, etc, The user can select a symbol group on the soft keyboard using a mouse, touchscreen, or keyboard navigation. The list of symbols in the selected group will appear in the auto-complete bar, so the required final symbol can be selected. Alternatively, one could display a large soft keyboard with all the APL glyphs on it, that the user could select from in a single step. Variable names and defined function names could still be entered via a standard ASCII hard or soft keyboard. 3c. In this scenario, the user knows the names of the glyphs. The user types variable labels and named functions using the ASCII keyboard, and speaks the names of the APL glyphs into a headset microphone. The speech recognition system determines the correct glyph to place in the edit window from the users spoken command. This could be one of the fastest ways to enter an APL-symbol version of J. For that matter, the complete single-glyph J program could be entered by speaking the glyph names as well as the variable and named-function names. 3d. In this scenario, the user just knows the actual APL single-glyph symbols. The user can type variable and defined function names on the ASCII keyboard, but the APL glyphs are entered on a touchpad or graphic tablet using handwriting recognition. This, along with the speech-recognition method is perhaps the most difficult to implement, but the handwriting recognition method has the closest match between what the user enters, and what is seen on the screen - which is a key point in any ease-of-entry requirement. With this set of options, we have a gradual way to move from ASCII-J to APL- glyph J with minimal issues. Ideally, the J editor would allow flipping back and forth between ASCII J and APL J displays at the click of a button. Veterans could work in their familliar ASCII J environment, but view the APL-J rendering at any time. Newbies would never need to see the ASCII J representation, as they could work entirely in the APL-J environment. Intermediate users could go back and forth between the two representations, though I expect that they would find the single-glyph representation easier to read. Old ASCII-J programs could be moved to APL-J by simply copy/pasting the ASCII J program in the new editor, and converting the representation to APL-J. APL-J programs could be viewed in ASCII-J using the same method in reverse. If the single-glyph entry problem can be implemented cleanly enough, the ASCII-J representation will gradually fade away. Everyone will eventually use the single-glyph version of J, both for entry and display. Skip On Mon, Apr 8, 2013 at 7:55 PM, PMA <[email protected]> wrote: > Remember I.P. Sharp's APL CHARACTER ROM chip? > I've still got mine! (But not its trusty IBM 8086 PC.) > > > PMA wrote: > >> Perhaps Wm meant something that _looks_ like >> an overstrike character without being physically >> entered as such. Either way, kudos. >> >> >> PMA wrote: >> >>> There we go! This sounds neat in just the way I'd hoped, >>> especially now with Wm's mention of _overstrikes_ for J. >>> Not so far, maybe, from the best of both worlds. >>> >>> BTW, I'd suspected that some of J's command groupings >>> make less sense than others. That's why I said "change, >>> perhaps...". >>> >>> Skip Cave wrote: >>> >>>> ... >>>> Also, to Peter, Yes. A one glyph-per-primitive notation will require >>>> many >>>> more symbols to implement than using ASCII character pairs as a single >>>> symbol. However, with well-designed glyphs, the "relatedness" between >>>> symbols will be as good or better than the two-character ASCII >>>> symbols in >>>> J. The APL character set is a testament to that. Look at the >>>> equals/not-equals glyphs in APL, and then compare that to the same two >>>> functions in J. APL wins out handily. >>>> ... >>>> >>> >> -- Skip Cave Cave Consulting LLC ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
