Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

More on ASCII APL

0 views
Skip to first unread message

ihuxi!otto

unread,
Apr 8, 1982, 5:07:11 PM4/8/82
to

Simply using lower case names for APL characters does not neatly handle
the problem of discussing APL strings in ASCII. Normally, to be
readable, such lower case names must be prefixed and suffixed with
blanks, but this can be incorrect in many cases. For example, what is
the meaning of the following simple string (origin 1)?

'delta slope bar epsilon or'[2]

This could be interpreted to be any of the following:

The APL "slope" character
The APL "slope bar" character
A blank

Compressing the spaces out to try to clarify the situation makes the
line difficult to parse by people (quick now, is the last character
in the string below a "nor" or an "or"?) and it still doesn't handle
the overstruck character problem:

'deltaslopebarepsilonor'[2]

The following may be ugly, but for practical situations it is clearer:

'@H....@E.OR'[2]

The beginning of each APL character is easily discerned, and (best of
all) it should be possible to write a simple C program to read in
strings like this, transform them into correct APL, and write them
out to disk for reading by an APL interpreter.


George Otto
Bell Labs, Indian Hill

rabbit!ark

unread,
Apr 9, 1982, 4:00:19 AM4/9/82
to
I do not see that the problem mentioned by ihuxi!otto is a serious
one, except for a special case that I will mention. First, each APL character
is a single entity, even if it is formed on a conventional terminal
by overstriking two characters. This is especially obvious to those
who have used APL 3270 terminals -- they have an extra case shift that
causes the "overstruck" characters to appear with single keystrokes.
Second, when you reperesent APL characters as lowercase words, you need
a rule to decide when a space adjacent to such a character is part of
the character and when it is a real space. It doesn't matter what the
exact details of the rule are, just that there be a rule and that it be
simple enough to know completely. One such rule might be that a keyword
is always preceded and followed by a "free" blank, unless the preceding
character is a left delimiter or the following character is a right
delimiter. A left delimiter is a quote, left bracket, or whatever,
and similarly for a right delimiter. Again, the content of the list
is not as important as its existence. Given this:

rho 'A rho B'

is unambiguously 3, as the spaces surrounding the second "rho" are part
of the symbol. Similarly,

'transpose X'[2]

is 'X' unambiguously.

The main problem with my proposal is that I have yet to figure out a way
of representing both the minus and negative signs that is not ugly.

0 new messages