You might be able to write a program that achieves this by writing
some kind of layer that handles all of the user input and output and
sends commands to a running J-server with your layer choosing how to
display the output. So creating a working prototype might be possible
by yourself. My point is that you could just do it and we can try
using it.
As for the notation itself. I am so used to the two-character ascii J
symbols by now that it is difficult to imagine any benefit for me,
personally, from learning another layer of symbols to decode.
If the symbols mean the same thing and there is a one-to-one
correspondence then I don't mind how they are displayed ... you just
get used to {. *: ^. etc. and read them as single words.
The benefit of displaying {. as {. though, rather than as a symbol
which is not on the keyboard, is that one instantly knows how to enter
it.
I do not know whether new users of J would find it easier with the
symbols compared to the two-character ascii method. Perhaps there
would be a benefit there, although you would still "see" the symbol
for {. and then have to look up how to enter it?
A bit off-topic, and completely irrelevant, but while thinking about
this I was reminded of the Commodore-16, my first computer, and
remembered that it had symbols on its massive keys. I just checked,
just-in-case, but the symbols were nothing to do with APL but were for
drawing seemingly random ascii shapes. What a waste!
http://upload.wikimedia.org/wikipedia/commons/a/af/Commodore_16_002a.png
On Thu, Mar 12, 2009 at 9:02 PM, Don Watson <[email protected]> wrote:
> Everyone seems to be talking about different issues than the one I was
> addressing on this thread. I would greatly appreciate help from anyone who
> is willing to read the paper and commented on it.
>
> In my proposal, nothing changes for J programmers. Keying is
> done in identical ASCII, storage is done in identical ASCII, transmission
> between systems is done in identical ASCII, mailing is done in identical
> ASCII and every user of J continues using ASCII in exactly the same way
> without knowing that anything has happened. The change is transparent and
> causes none of the difficulties that are being discussed.
>
> The change is solely intended to assist those who are learning Mathematics
> and very casual users of J. It allows them, in effect, to say to the system:
> "When you come to write my J language statements to the screen or to the
> printer, I want you to look up every two character primitive in which the
> second character is a "." or a ":", in a table and use the special symbol
> you find there instead - that's all. This is easy to do.
>
> There is a second component to the proposal to do with adding a second kind
> of fork. Again, it is an addition that no J programmer need know
> anything about or ever use. It is proposed that for this fork any J
> expression is permitted on either branch of the fork and to the left of the
> fork - not just a verb. This makes it lot easier to parallel mathematical
> formulae in tacit programming for those learning to apply mathematical
> formulae.
>
> The handwritten script I posted was a mess and the pdf form was not popular.
> I have created the primitive symbols in Paint and added them into a word
> document. This revised paper has now replaced the previous one at:
>
> http://bcompanion.com/Compromisedoc.doc
>
> Thanks
>
> Don Watson
>
> ----------------------------------------------------------------------
> 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
