inca: a hacked-up apl in c based on the J incunabulum

[Kenny McCormack]

If you're trying to write conforming modern C,

I think it is pretty clear that that's the last thing on "luser"'s mind or
list of goals and intentions.

you need to remove *all* occurrences of implicit int.

He "needs" to do no such thing. Besides, I thought that C89 was still the
only "real" standard endoresed by the regs here.

A void function needs to be declared with
an explicit return type of "void".

There you go again. Telling people what they need.
How paternalistic of you!

The "implicit int" feature was removed from the language by the C99
standard.

Which means it is perfectly legal and OK by all standards bodies (including
you, Mr. Kiki!) in C89 code (which is what most people still write).
....

which I see is where the horrid macro definitions:

Keep your editorial comments to yourself, please.

Although the code is terse and may seem unreadable at first,
it can be understood with a little effort. It may help to
understand that the code was written for and by people who
were very familiar with array-centric languages (APL) and who
came from a strong mathematical background. Indeed, one of the
main reasons for adopting a style like this is that it meakes
it easier to reason about and manipulate the code algebraically.

Indeed. So get off their backs, OK!

I'm not convinced about the claimed advantages of the style,
though I suppose it's possible I'm missing something.

We're not here to convince you - or to gain your approval.

Go away!

--
"Although written many years ago, Lady Chatterley's Lover has just
been reissued by the Grove Press, and this fictional account of the
day-to-day life of an English gamekeeper is still of considerable
interest to outdoor minded readers, as it contains many passages on
pheasant raising, the apprehending of poachers, ways to control vermin,
and other chores and duties of the professional gamekeeper.

"Unfortunately, one is obliged to wade through many pages of extraneous
material in order to discover and savor these sidelights on the
management of a Midlands shooting estate, and in this reviewer's opinion
this book cannot take the place of J.R. Miller's Practical Gamekeeping"
(Ed Zern, Field and Stream, November 1959, p. 142).

 

[James Kuyper]

On 03/28/2014 11:42 AM, Keith Thompson wrote:
....

I found this:

https://github.com/tangentstorm/j-incunabulum

and in particular this:

https://github.com/tangentstorm/j-incunabulum/blob/master/ji.c

which I see is where the horrid macro definitions:

#define P printf
#define R return

came from. It's based on some code written in 1989, which probably
explains the use of implicit int. Quoting the README.md:

Although the code is terse and may seem unreadable at first,
it can be understood with a little effort. It may help to
understand that the code was written for and by people who
were very familiar with array-centric languages (APL) and who
came from a strong mathematical background. Indeed, one of the
main reasons for adopting a style like this is that it meakes
it easier to reason about and manipulate the code algebraically.

I'm not convinced about the claimed advantages of the style,
though I suppose it's possible I'm missing something.

APL's syntax does indeed make it easier to "reason about an manipulate
the [APL] code algebraically". However, that C coding style provides no
such benefit.

 

[Öö Tiib]

In your attempt, the spacing was off.

Programs that crash or hang on any input (regardless
if "spacing was off" in input or other such silly
reason) are dangerous trash.

Crash means it is often possible to overtake system with
malicious input, hang means that it is vulnerable to DOS
attack.

So ... learn to program, pal.

 

[glen herrmannsfeldt]

(snip)

Talking about APL, I just found out that the Computer History Museum
(computerhistory.org) has the source from IBM for APL\360.

As usual, for non-commercial use and no redistribution.
(You have to agree to the license terms before downloading.)

I am not sure what the rights would be if you rewrote it in C.

-- glen

 

[Kaz Kylheku]

Talking about APL, I just found out that the Computer History Museum
(computerhistory.org) has the source from IBM for APL\360.

As usual, for non-commercial use and no redistribution.
(You have to agree to the license terms before downloading.)

`Cause if you violate this, some little old man will show up at your door and
beat you with his cane.

(Actually he will beat you with a toothpick which denotes the
semantics of being whipped in parallel with 1000 canes.)

 

[BartC]

(snip)

Talking about APL, I just found out that the Computer History Museum
(computerhistory.org) has the source from IBM for APL\360.

As usual, for non-commercial use and no redistribution.
(You have to agree to the license terms before downloading.)

I am not sure what the rights would be if you rewrote it in C.

It seems to be written in assembly code (360 I guess, judging from the "L"
opcode I recognised).

You will have your work cut out in rewriting it in anything, as it is likely
closely tied to that platform. Suddenly luser- -droog's version doesn't
seem so bad after all!

 

[glen herrmannsfeldt]

(snip, I wrote)

(snip)

It seems to be written in assembly code (360 I guess, judging
from the "L" opcode I recognised).

From that time frame, most was written directly in assembler,
but later in an internal PL/I-like language, compiled to assembly
code, and only the generated assembly code was released outside IBM.

You will have your work cut out in rewriting it in anything,
as it is likely closely tied to that platform. Suddenly
luser- -droog's version doesn't seem so bad after all!

-- glen

 

[luser- -droog]

I've done some work with the source. The results are here:

http://pastebin.com/7J0tfbJU

Mainly, replacing I by INT, A by ABC (to make things simpler for my editor),
and giving more vertical space to the functions. Ideally everything there
would be one statement per line, and the code would be consistently
indented, but I guess tools exist to do all that.

The overall structure is now a bit clearer (especially after I figured out
that V1 and V2 define functions), but it still looks quite complex to fully
understand. (Not knowing APL doesn't help.)


The code is also still very fragile: most things I type in will crash it.

I've adopted some of your substitutions,
but I've run into trouble get it to do
general matrix multiplications. I suppose it's
a harder task than I forsaw. It did take them
a long time the first time.

 

[luser- -droog]

It seems to be written in assembly code (360 I guess, judging from the "L"

opcode I recognised).

You will have your work cut out in rewriting it in anything, as it is likely
closely tied to that platform. Suddenly luser- -droog's version doesn't
seem so bad after all!

For anyone attempting to write an APL from scratch, one of
the best design documents I've found is this one from 1972
which describes an APL Machine as a microcode emulator
for the IBM 5100 to work with the system 360 emulator.
http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/apl/An_APL_Emulator_Jun72.pdf

While there are many similar documents available describing
everything from IVSYS on the 7090 through the SV and later
versions, but this 1972 document gives many more memory
map examples showing the organization of the low-level
data structures in much more detail than most other write-ups.

Incidentally, inca has acquired some new bizarre features,
such as template code generation. It's now pushing 1000 lines.

$ ./inca
i<:0!1+~y
7
0!1+~y
o<:0=1+~y
7
0=1+~y
u<'ox),'iy
10
('ox),'iy
2"u3
5
0 0 1 1 1
!5"u9
14
1 1 1 1 1 0 0 0 0 0 0 0 0 0
r<40.'iy);(1+~<y);((0{:").'iy);((0{:u).'iy);(@~<y);(41.'iy);((0{:.'iy-1),0
76
(40.'iy);(1+~<y);((0{:").'iy);((0{:u).'iy);(@~<y);(41.'iy);((0{:.'iy-1),0
'r3
7 3
40 40 40
-2147117200 -2147117104 -2147117008
20 20 20
117 117 117
-2147115616 -2147115648 -2147115680
41 41 41
23 23 0
$,\@`
21
(1"u2);(2"u1);(3"u0)
;`
3 3
0 1 1
0 0 1
0 0 0