Matthew, I agree that it would be vital for such an editor to support basic text as well as any of the fanciness I am advocating. I imagine that there would be the following three modes: ASCII only, interlinear symbols and ASCII, and symbols with revelation of underlying ASCII upon "hover" with the pointer.
Also, with a few exceptions (such as @ and @:) I imagine the symbols for J primaries being very, very close to the ASCII versions. What I have in mind is more of a typographic smoothing than a serious substitution. For example, I suggest that different styles of ampersand be used for & and &: than for &. and &.: so that it is clearer which sort of thing is occurring. But, in every case the basic form would be ampersand and the variant would visually suggest the inflection(s) involved. Similarly, the various primaries composed of some combination of point, comma, colon and semicolon would all retain their basic structure, but would be individualized so that the unity of each symbol would be accentuated and darkness increased. A big part of what I'm looking for is to reduce the degree to which J code involves a scattering of dots by favoring signs that are distinctive and apparent. I've made many scribbled notes along these lines over months. They have helped me in the process of memorizing J primaries, if nothing else. Tracy On Mon, Feb 23, 2009 at 11:51 PM, Matthew Brand <[email protected]> wrote: > If all the code is displayed with symbols such as is being considered > but the entry method remains via ascii keyboard then it will make it > more difficult for new potential J users to get into J. > > They would have to look up on a card what combination of keys to press > to make the symbols appear. i.e. they would know they need to use the > "small filled circle" to do a composition, but they will not see a > "small filled circle" key anywhere on the keyboard. > > With ascii display they would know they need a @: for composition and > can glance at the keyboard and quickly enter it. > > Eventually they might memorise the pattern of "shift-2" "shift ;" (on > a Mac keyboard) to make the "small filled circle appear", but another > layer of language learning would be added. > > For existing J programmers the story would be different. We already > know that @: is composition and would automatically press the correct > key combination and would likely benefit from the prettier display. > > This problem could be solved by having an option, button or > key-combination to toggle the display between the two modes. So you > would by default see the new display character set, but if you hold, > say, ctrl-shift-g (or whatever!) then the display changes to show the > ascii. That way users would not have to "look up" how to enter each > symbol. > > > > On Tue, Feb 24, 2009 at 2:14 AM, Tracy Harms <[email protected]> wrote: >> Don Watson initiated a conversation under the title "Teaching" on the >> General forum. I'd like to sketch out some further thoughts along >> these lines. >> >> Among the most important strengths of J are its notational nature and >> its extraordinarily simple, general syntax. The spelling of its >> primaries, while semantically admirable in ways that have been >> elaborated by others, leads to difficulties of recognition. Iverson's >> notation eliminates the syntactic patterns that are rooted in spoken >> language, which means that cues we commonly rely upon to identify >> patterns by sentence structure are missing. A good deal of concision >> results from that choice, but it means that many more elements must be >> interpreted on their own rather than within a larger pattern. >> >> The difficulty with two-character primaries is not that they are less >> concise. The extra length is irrelevant. The difficulty comes mostly >> from the fact that the primary symbols have been constructed from >> characters that evolved as minor modifiers; they are hard to read >> because their primary use relies on their being unobtrusive. Take a >> text, eliminate all the punctuation, and you have a text that does not >> look very different from the original. Even the space character is in >> this class. (Most ancient languages were written without spacing >> between words.) Punctuation characters are not well suited to be >> understood on their own, in large part because many look very much >> alike, and especially because they are mostly diminutive. >> >> Mind you, ASCII punctuation marks are what K.E. Iverson had to work >> with. He did a fine job with what he had, but his work here was >> distinctly bricolage, in contrast with his original decision to use >> symbols that extended his success at the chalkboard. >> >> I agree with Don (and several others) that J will benefit from >> improved display, and that this can be accomplished without departing >> from the established spelling of J primaries. At this moment I won't >> elaborate on particulars except to say that I envision @: being >> displayed as a small black circle (a.k.a. bullet) and @ as a small >> unfilled circle (as in the math notation that inspired it.) >> >> Let me go beyond the idea of replacing, (for display only, not typing >> or text editing,) J primaries with improved (but visually similar) >> symbols. What I think J naturally leans toward is having symbols stand >> in for defined names. Again, this can be done while having the text >> that is typed (and also copied, pasted, and saved) be standard text, >> but the display show something else. The defined name could be 'Aleph' >> and the display be the Hebrew character of that name. All the Unicode >> characters would be readily available in this manner. Other symbols >> could be supported, too. In fact, they can include hieroglyphs, in >> which case Donald McIntyre's phrase "from hieroglyphics to APL" will >> look more like a circle! >> >> Long variable names strain the symbolic structure in which J is >> strongest. Symbolic substitution for defined values will amplify one >> of J's greatest strengths. (Haskell's support for user-defined >> symbolic operators is worth noting, here.) I anticipate that once >> editors are built that support this sort of visual enhancement they >> will be favored in many circumstances, perhaps most. >> >> No change whatsoever would be needed from J Software for such a thing >> to occur; the language specifications would persist untouched. >> >> >> Tracy Harms >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > > > > -- > http://www.ixquick.com/ > > Ixquick Protects Your Privacy! > The only search engine that does not record your IP address. > > http://www.vivapalestina.org/ > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
