euaheb@eua.ericsson.se (Harald Brandt) (12/06/90)
This is a note on some bugs, or possible bugs, I have found in J. I figure it
might be valuable to report bugs found, so as to inform the designers of the
interpreter and other users. Some of these bugs may be known already, or may
not really be bugs but mere misunderstandings. First I thought of sending this
only to ljdickey, as you are a bit involved in J and may therefore perhaps
forward reports on bugs to ISI (or should I send a copy by surface mail to
ISI?). However, I decided to post this to the newsgroup so other people can
share experiences or inform me of better knowledge (at the risk you think I am
cluttering the newsgroup with junk of course). I use J version 2.8 on a
Macintosh II with a 13" color screen, System 6.0.5, 4 Mbyte RAM, J is set to 1
Mbyte.
1. Infinity in the Power conjunction
I tried the expression on top of page 9 in the J Dictionary that comes with the
J package. It solves y = cos(y). The following is an excerpt from a dialog
(copied from the session, so I KNOW there are no retyping errors):
2&o.^:_ (1)
ill-formed number
2&o.^:99 (1)
0.739085
2&o.^:_99 (1)
0.962266j1.11097
The first input should have worked, since the document 'status.doc' doesn't say
anything about limits on the the '^:' conjunction and the infinity symbol '_'.
The second input shows that the conjunction works fine with number 99, and the
third input shows that the character '_' is okey as a negative number. So
something is wrong with the very useful infinity (or asymptotic) case.!
2. The Definition conjunction
I tried the code in the article of 20 Sept: <12061@chaph.usc.edu>
The function 'read' was defined as: 'read =. 1!:1' (reads characters from the
keyboard). The following is an ecerpt from my session:
set =. (read 1 )::''
spelling error
set =. (read 1 ) ::''
(y.,'=:y.') :: ''
set 's'
syntax error
The first input shows that J refuses to accept a parenthesis immediately to the
left of '::' whereas J did in the article. The second input shows that J
accepts the sentence when I add a blank inbetween the parenthesis and the '::'.
Is this a bug, or is it intentional? I can not deduce from the parsing rules or
elsewhere in the J dictionary that there must be a blank there.
(Just today I read a posting by ljdickey that he experienced the same thing
with version 2.7 for Atari, but that does not explain why.)
The third input shows that the 'set' function doesn't work even though it
swollowed the definition of 'set'. For what reason I do not know. Is this a
bug, or is that nestling of definitions illegal? (I.e is article
<12061@chaph.usc.edu> based on lies or an erronous interpreter?)
3. The Merge adverb
Page 16 in the J Dictionary describes the merge adverb. Specifically the
following sentence there confuses me: "More generally, the shape of x may be a
suffix of the shape of j, and the result is a merge of ($j)$,x and y.". Either
I do not understand it, or it does not work as the definition says. The
following is an ecerpt from my session, where 'am' is a character matrix I
created for test purposes:
am
asdfgh
jkloaz
xcvbnm
qwerty
uiopaa
(2 2$'ASDF') (2 2&$0 2;4 4; 2 3;2 2)} am
asAfgh
jkloaz
xcFDnm
qwerty
uiopSa
(1 2$'ASDF') (2 2&$0 2;4 4; 2 3;2 2)} am
length error
('ASDF') (2 2&$0 2;4 4; 2 3;2 2)} am
length error
(3 2$'ASDF') (2 2&$0 2;4 4; 2 3;2 2)} am
length error
('AS') (0 2;4 4; 2 3;2 2)} am
length error
('A') (2 2&$0 2;4 4; 2 3;2 2)} am
asAfgh
jkloaz
xcAAnm
qwerty
uiopAa
The first long input shows the normal behavior (although the 2 2$ seems
meaningless, it is in accordance with the definition). The next four inputs
yielding "length error" are various tests that I would have expected to work
according to the definition (or what else does "suffix" mean?). The last one is
the only that works, but that is only because it is an atom left argument. What
is actually meant or intended?
4. Stiff Window
The J-window I get (console) has no scroll-bars and cannot be increased in
size, but when clicking and dragging at the bottom right corner (where resizing
normally is done) dotted lines of imaginary scroll-bars show up, so the Mac
obviously expects the window to be of the standard resizable scrollable type.
This, however may not be a real bug, but I find it hard to believe that a
programmmer does not make use of the standard scrollable window that comes
almost effortless for free in a Macintosh! That is why I suspect it is a bug
(or a bit too lazy implementation).
Regards/ Harald