We have to be careful when we make the assumption that there will only be a standard 110-key keyboard with every computing device from now on. Or that keyboards will be unable to change the labels on their keys arbitrarily. Or that all input will always be done by typing on a keyboard.
The available input methods for our computing devices are already broadening, and there will only continue to be even more options (3D hand gestures anyone?) I could envision a system where there are simply a lot more keys on the keyboard. Or where the keyboard labels change, depending on the mode. Or perhaps the programmer types the alphanumerics, and speaks the glyph names, or perhaps hand-writes the glyphs at the appropriate times, while typing the alphanumerics. Perhaps we have auto-competion of primitive names, so the the glyph shows up as one of the auto-compete options when you type the first few letters of the ASCII name of the primitive. The critical idea in *all* cases should be that the printed or displayed glyphs should have a *direct* correlation with the data entry method - press the glyph key, speak the glyph name, write the glyph form, type the glyph name using ASCII alpha characters, whatever. All these methods should produce the *same* glyph notation. There should never be an underlying secondary notation like Knuth's TeX, that doesn't correlate very well graphically with what the final output will look like. The better the data entry method matches the visible glyph, the easier it will be to remember how to enter the glyphs. 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.. With modern computing devices, trying out any of these approaches is possible - a 150-key soft keyboard with ALL the possible single-glyph symbols in the language on it, a soft keyboard with several modes where the key labels change for each mode to cover all the glyphs as well as ASCII, the type-n-talk system where alphanumeric characters are typed on a hard or soft keyboard and glyphs are spoken, the same setup with the alphanumeric keyboard where the glyphs are drawn on a touchpad or touchscreen, or the auto-compete scheme. Technology has provided us with all the tools we need to solve the data entry problem for a sinle-glyph language. Unfortunately, Ken Iverson didn't have these technologies 50 years ago, so he had to compromise on his notation. Now we don't need to compromise any more. We have the tools. We just need to pick the right ones. Skip On Mon, Apr 8, 2013 at 4:47 PM, William Tanksley, Jr <[email protected]>wrote: > Skip Cave <[email protected]> wrote: > > William, > > You are overlooking the option of writing the single-character glyphs on > a > > touchscreen, using handwriting recognition. > > That sounds like a pleasant way to augment a keyboard-based entry if > we decide to go with glyphs that don't resemble the underlying > characters -- if you can't remember the keystrokes but do remember the > glyph, just sketch it. (The font for the glyphs could even be designed > so that the way to sketch it is obvious -- which implies another > tradeoff.) > > OTOH, I'm not seeing this as a useful _replacement_ for keyboard input > at our present level of technology. Maybe I'm wrong. > > > Skip Cave > > -Wm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Skip Cave Cave Consulting LLC Phone: 214-460-4861 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
