One of the unfortunate things about mapping between a single graphical symbol
in a front end and a train of symbols on the other side would be that analysis
and manipulation of source code will be complicated. The construction and
execution of "domain specific notations" has always been one of the key
strengths of APL and I suspect also J - and easy manipulation of code is an
important part of enabling that.
For example, what is the result of typing
#'1€2'
... if € is a graphical symbol which the frontend maps to 2 or 3 characters?
So: My feeling is that J would need to adopt a graphical symbol set at the
interpreter level for this to really fly. I would love to see this but I think
it is quite tricky - even with the Unicode set at your disposal - to find a
nice set of symbols to map all the new J functionality to.
Someone has to try it: If it hasn't been done by the time I retire this will be
at the top of my to do list :-)
Morten
-----Original Message-----
From: Tracy Harms [mailto:[EMAIL PROTECTED]
Sent: 19. december 2007 23:03
To: [email protected]
Subject: [Jchat] J readability
Donna wrote:
> To be readable you need to be able to recognize the morphemes,
> words, and sentences which is easy in APL and not so in J.
I agree. We notice this, and we also notice that this was a cost K. I.
paid in moving his notation to ASCII.
In comparing APL with J, the relative problems of J arise from the fact
that J does more with less. The reliance on standard punctuation marks
is doubly difficult. First, there is the clash with pre-established
meaning. J primaries have been constructed quite cleverly, but the
normal meanings of the components still tend to vie for attention.
Second, punctuation marks tend to be slight and spare, and the
interpretation of punctuation is aided by many aspects of the context in
which it occurs. Leaning on these little things as heavily as J does
runs contrary to what naturally evolves in manual writing. There are
systematic reasons that many punctuation marks are little or relatively
indistinguishable.
Since APL symbols were designed for mnemonic clarity, their replacement
with combinations of punctuation marks makes for a notation that is
harder to read. This isn't news, and it isn't a scandal.
I do think it will be possible to enhance J, symbolically, so that it
reclaims benefits of classical APL. My vision is that each J primary
will continue to be specified with basic text, but the resulting display
will be an appropriately mnemonic glyph. The adjoining characters that
make up primary tokens would, in such an interface, serve in a manner
similar to the early APL overstrike combinations described recently in
this forum. Wherever the insertion point occurs the literal J code would
be seen, but otherwise it would have a visually 'translated' form.
I don't think such a project is worth making a high priority, however.
Even less do I think that it would make a major difference in how widely
used J becomes. The niche status of APL indicates that an implementation
of J that looked more like standard APL wouldn't wow the world at large.
Tracy Harms
P.S. I actually am not in a position to agree that recognizing words and
sentences is *easy* in APL, as my skill in it is minimal. Yet, even
given my standpoint of ignorance, APL does seem to radiate clarity.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
