I still think making the libraries + argument conventions more navigable would be a more productive and better received application of the VS IDE.
I did enjoy seeing Mark Simpsons APL to J mappings. Visually things like square root and not made more sense. With this symbol variation approach I'd think that there'd be a tendency to shy away from embracing the potential of unifying similar notions with conventions such as inverse, stop, colon should people use a visual APL type bridge to J. It's a worthwhile experiment, but it definitely sounds like a fork in the road. Should we recognise this as such? On 9 April 2013 05:09, Skip Cave <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
