Getting started
Anthony Sorace
great APL was. intruiged, i did some reading of Iverson's old stuff and
old IBM APL terminal documentation, but didn't think much of it, since
even the guy who first told me about it seemed to think it was dead. i
was quite pleased to find he was wrong (and so was he) when i picked up
an A+ CD at UseNIX this June.
so now i'm quite intruiged again, and have been reading this group for
about a month now. but i'm having trouble really getting started, and am
hoping for help here.
first, i've noticed frequent discussions around character set
incompatabilities between various APL derivatives. do any of them use
unicode, wich has APL glyphs in it? unicode would seem to be a
reasonably accepted standard people could probably agree on.
second, i run a pretty odd OS (Plan 9). while i've no aversion to paying
(reasonably) for things, A+ seems to be the only APL environment that
gives out source, thus the only one i have any hope of running locally.
are there others?
third, i'm somewhat unclear on the relationship between APL and K/J. are
they derivitives/evolutions of APL, or inspired works, or simply other
languages in the same family? and K and J's relationship to each other?
finally (for now), i've heard about an APL->C compiler. pointers and
oppinions appreciated.
much thanks from an enthusiastic beginner.
anothy
David Ness
> second, i run a pretty odd OS (Plan 9). while i've no aversion to paying
> (reasonably) for things, A+ seems to be the only APL environment that
> gives out source, thus the only one i have any hope of running locally.
> are there others?
Dealing with Plan 9 in its current state and attempting to learn A+ at the
same time sounds like a double bite of the apple to me. I'd advise against
it. You will constantly be spending major amounts of time figuring out things
on both sides that are distractive.
> third, i'm somewhat unclear on the relationship between APL and K/J. are
> they derivitives/evolutions of APL, or inspired works, or simply other
> languages in the same family? and K and J's relationship to each other?
Iverson, after doing APL, moved to J.
Whitney, after doing the early parts of A/A+ at Morgan Stanley left and developed K. (I think)
There is a record of a `historic' meeting between Iverson, Whitney (and I assume
others) where Whitney took out a piece of paper and sketched on one page the rudiments
of what was to become A -> K
So there are lots of common threads...
Jim Lucas
> so now i'm quite intruiged again, and have been reading this
> group for about a month now. but i'm having trouble really
> getting started, and am hoping for help here.
The following are my personal viewpoints and opinions. Others may differ.
> first, i've noticed frequent discussions around character set
> incompatabilities between various APL derivatives. do any
> of them use unicode, wich has APL glyphs in it?
As far as I know, none of them use Unicode internally.
> unicode would seem to be a reasonably accepted standard
> people could probably agree on.
Unicode seems to reasonably accepted by the hawkers of standards, but far from
universally implemented even partial form (except for the ASCII subset, of
course). It appears to me that it will be some time before it becomes widely
implemented... and I don't just mean in APL.
Also, Unicode is an encoding standard for storage and output of text. It says
nothing about input. And -- for me at least -- it loses much of its utility if
I can't type it into my word processor using the same keystrokes as in my APL
session.
Experienc tells me that "people" can rarely "agree on" anything, though they
will often allow themselves to be forced into doing things in a common way.
> second, i run a pretty odd OS (Plan 9). while i've no aversion
> to paying (reasonably) for things, A+ seems to be the only
> APL environment that gives out source, thus the only one i have
> any hope of running locally. are there others?
I believe that the source code for an ancient version of J is still available,
but the current version (no source available) is significantly evolved over the
open source.
Personally, I would recommend that you get yourself a cheap PC running Linux
(and/or Windows). I'm pretty sure you can get something adequate for
experimentation for well under a thousand dollars. As "time is money", I would
think that this would be the most cost-effective way to learn enough to decide
whether you want to go invest even more time.
Once (if?) you become addicted, you might consider doing a port. But until
you're familiar with the language and its capabilities, you're unlikely to know
how to properly test your port, and the time and difficulties (guaranteed to be
some) taken in (trying to) port A+ would just postpone your learning of APL.
And you may have noticed a recent discussion regarding the difficulty of
porting the A+ GUI.
> third, i'm somewhat unclear on the relationship between APL and
> K/J. are they derivitives/evolutions of APL, or inspired works, or
> simply other languages in the same family?
All of the above. J is, in my opinion, a dialect of APL. It is closely
related to the Sharp APL dialect(s), particularly the SAX (Sharp Apl uniX)
implementation, the Linux version of which is now available for free download
(for personal use).
There those who maintain that J is not really APL, and a major argument seems
to be the use of an all-ASCII symbology. I feel that this is like claiming
Croatian and Serbian to be different languages because Croatian uses the Latin
alphabet, while Serbian uses the Cyrillic alphabet. The fact is that the
spoken languages are closer than many dialects of English.
As I see it, aside from the different alphabet, J is as closely related to SAX
as SAX is to APL2, though the distance between J and APL2 *is* greater. But
frankly, I don't particularly care how people want to label it (APL,
son-of-APL), it is still useful, and it will teach you the principles which are
shared by all APLs.
I once considered A+ to be a descendant of APL, rather than a dialect, because
it included certain features which I associated with C, rather than APL. The
main one, however, was Control Structures. Now, most APLs include Control
Structures, and most of the rest are trying to decide how to implement them.
So the distinction is gone, and I now consider A+ to be simply a dialect of
APL.
K, on the other hand, is definitely not APL, though it is clearly descended
from it. Another major influence on its design seems to be LISP. Like J, K
composes its symbols strictly from ASCII characters, but the details of its
symbology -- as well as its syntax -- are quite different from J's.
and K and J's relationship to each other?
Add A+ to that. A+ was developed by Arthur Whitney. So was K, but starting
from scratch, not by building on A+. (So was an earlier version of APL for
certain HP computers, which included some interesting innovations, but was
basically Sharp APL. Unfortunately, it never saw wide distribution.) J was
developed by Roger Hui and Ken Iverson. They are both personal friends of
Arthur's, and I believe there was frequent contact among them during the early
stages of development of each of those three languages. Roger's coding style
in C (all three are implemented in C) is said to have been strongly influenced
by Arthur's C coding style. Nevertheless, the language designs -- in both the
choice of syntax and the choice of what particular functions and operators to
include as primitives -- are all clearly independent.
> finally (for now), i've heard about an APL->C compiler.
> pointers and oppinions appreciated.
I've heard of more than one. As far as I know, they all exclude certain
dynamic features of APL in order to be able to perform their compilation. Even
if they were generally available and free (which I don't think any are), I
would recommend becoming familiar with interpreted APLs (or J or K) first, 1)
so you can see and evaluate the differences, and 2) because they offer much
better learning environments.
> much thanks from an enthusiastic beginner.
Good luck, and have fun, /Jim Lucas
Mike Kent
> Personally, I would recommend that you get yourself a cheap PC running Linux
> (and/or Windows). I'm pretty sure you can get something adequate for
> experimentation for well under a thousand dollars.
Just for fun, I checked the clearance page at
Egghead. They have a Toshiba M510D with a P3/733,
a 20 GB disk drive, 40x CS, 8Mb nVidia graphics
card, and 10/100 ethernet for $530, + $10 for
shipping in the US lower 48. No OS and only 64
MB of RAM but for $30 + $200 one could get the
"official" RH Linux 7.1 and 1GB of Crucial RAM.
That would probably be "adequate for experimentation",
at about $770. The box will take another P3 and
up to 2GB RAM, if one's experiments are more demanding
but that would push the price (just) over $1000.
Jim Lucas
> A+ was developed by Arthur Whitney. So was K, ...
> J was developed by Roger Hui and Ken Iverson. They are
> both personal friends of Arthur's, and I believe there was
> frequent contact among them during the early stages of
> development of each of those three languages.
What I neglected to mention is that I believe before A+, J, or K the three all
worked together at I.P. Sharp Associates. This was the period during which the
rank operator (among other things) was first implemented... in Sharp APL, of
course.
/Jim Lucas
Jim Lucas
> Anthony Sorace wrote:
> > third, i'm somewhat unclear on the relationship between APL
> > works, or simply languages in the same family? and K and J's
> > relationship to each other?
>
> Iverson, after doing APL, moved to J.
In greater detail: Some time after writing "A Programming Language" Ken went
to work for IBM, where APL was subsequently first implemented. Some years
later he left IBM and went to work for I.P. Sharp, where he had an important
role in the evolution of that "dialect" of APL. Subsequently (I don't remember
whether before or after the Reuters buyout of I.P. Sharp), he left Sharp and
formed Iverson Software (which in the beginning distributed a PC version of
Sharp APL), which has since become J Software.
> Whitney, after doing the early parts of A/A+ at Morgan Stanley
> left and developed K. (I think)
Before Arthur was at Morgan Stanley, he worked for I.P. Sharp, which I believe
is where he got to know both Ken and Roger, who were also working there. After
they "went their separate ways", I understand they still kept in close touch
and frequently exchanged ideas.
By the way, Roger seems to be less talked about than either Ken or Arthur, but
I believe that he was instrumental in the development of SAX (Sharp Apl uniX),
among other things.
A/A+ was developed by Arthur under exclusive contract for Morgan Stanley. I
believe Morgan Stanley held/holds exclusive rights, and *they* recently started
making A+ available to the public. The first "commercial" use of K -- and much
of its development -- was also under exclusive contract... to UBS (Union Bank
of Switzerland). But Arthur had learned something from his Morgan Stanley
experience, and the contract he negotiated with UBS was time-limited, after
which he would be free to sell it openly. For this we are all grateful. (We
will probably never know, but I wonder if the open availablility of K wasn't a
significant factor in the eventual decision to release A+.)
> There is a record of a `historic' meeting between Iverson,
> Whitney (and I assume others) where Whitney took out a piece
> of paper and sketched on one page the rudiments of what was
> to become A -> K
I'm not absolutely sure, but I believe that was just K. K did not really
"evolve from" A, though the basic ideas of K almost certainly began to evolve
in Arthur's mind during the years of his work on A/A+, if not before.
Several of those principles are quite different from those of A/A+/APL (and J).
These include lists (and lists of lists) rather than arrays of arbitrary rank
as the fundamental data structure, consistent extension of bracket-semicolon
notation, unlimited argument valence, limitation of infix notation to primitive
functions, projection, etc. I believe it was at APL93 in Toronto that he
showed me on a notebook computer his first tentative implementation of K and
explained to me some of the thinking behind it.
> So there are lots of common threads...
Indeed there are. I think it's also interesting that the close communication
between Arthur and the J developers does not seem to have been matched by the
various groups developing "APL2-compatible" versions of APL, though I believe
such closeness did exist among the various APL developers (at IBM, I.P. Sharp,
and STSC) during the 1970s. Just as Arthur, Ken, and Roger had been colleagues
at Sharp, several of those folks had previously worked together at IBM.
/Jim Lucas
David Ness
>
> In greater detail: Some time after writing "A Programming Language" Ken went
[Snip of an interesting summary of APL/A/J/K History]
Edifying.
Jim Lucas
Maybe someone else(s) could supply some history of other APL development
efforts and their people. APL2 is the most obvious, but there are also APL+,
Dyalog APL, APL6800, as well as some of the other efforts that aren't -- and
perhaps never were -- as well known. (DEC, Data General, Analogic, APLs for
the TRS80 and Apple II, Q Nial, others whose names I can't remember...; and
people, such as Jim Ryan...).
How about it?
/Jim
Anthony Sorace
// Dealing with Plan 9 in its current state and attempting to
// learn A+ at the same time sounds like a double bite of the
// apple to me. I'd advise against it. You will constantly be
// spending major amounts of time figuring out things on both
// sides that are distractive.
well, having run Plan 9 for about four years now, i don't spend
much time at all "figuring out things" on that. it's current
state is certainly the best it's been, and quite stable (as in
the fundamentals don't change much). it's certainly the most
productive environment for me, and i'm pretty sure i'd waste
more time working in some foreign environment.
much thanks to you and jim lucas for clearing up the history
around APL, J, K, and A+. very informative.
: anothy;
David Ness
>
> well, having run Plan 9 for about four years now, i don't spend
> much time at all "figuring out things" on that. it's current
> state is certainly the best it's been, and quite stable (as in
> the fundamentals don't change much). it's certainly the most
> productive environment for me, and i'm pretty sure i'd waste
> more time working in some foreign environment.
>
> much thanks to you and jim lucas for clearing up the history
> around APL, J, K, and A+. very informative.
> : anothy;
Well, I appreciate your words about Plan 9. And if you do decide to
take that route, I'd appreciate it if you'd keep in regular contact
about your progress. Some of the Plan 9 people were tremendous
influences on me in earlier stages of my career, and though I only
follow their current work from a distance (there is, after all, only
so much time), if it is really getting stable, as you suggest, it may
be time to pay some closer attention again.
Anthony Sorace
// Unicode seems to reasonably accepted by the hawkers of
// standards, but far from universally implemented even
// partial form (except for the ASCII subset, of course).
// It appears to me that it will be some time before it
// becomes widely implemented... and I don't just mean in APL.
in my experience, this is true in principle, but not nearly as
bad as you make it sound. many tools are still blisfully
ignorant of Unicode, but an increasing number of systems are
including support for it, including Solaris, BSD, and various
other Unixes (and, of cource, Plan 9). even Win32 has limited
support for it, and improving.
// Also, Unicode is an encoding standard for storage and output
// of text. It says nothing about input. And -- for me at
// least -- it loses much of its utility if I can't type it
// into my word processor using the same keystrokes as in my
// APL session.
well, true, but Unicode hardly affects that problem, does it?
you got it exactly right - Unicode says noting about input,
that's up to your tools. but how much agreement between your
tools do you have now WRT APL text?
// Personally, I would recommend that you get yourself a cheap
// PC running Linux...
people toss this around like $700 is nothing. sorry, but that's
still a nice chunk of cash for me. not to mention things like
desk space.
// As "time is money", I would think that this would be the most
// cost-effective way to learn enough to decide whether you want
// to go invest even more time.
well, maybe. keep in mind that a) i'm going to be much less
productive in any alien environment, let alone one i consider to
be inferior b) i'm getting something extra out of doing it on my
platform (as might both communities), impacting the cost/benefit
analysis. however, i've been muchking around with the A+ disk
Morgan Stanley was giving out, it being a bootable linux disk
(nice thinking, guys). it's not as comfortable as i'd like, but
it's been enough to convince me i want to know more.
// Once (if?) you become addicted, you might consider doing a port.
wouldn't be the first time. when i started using perl for a unix
web project i was working on, the first thing i did was port it to
Plan 9 (the existing plan9 port in perl having been for _much_
older perl and plan 9 versions). worked on python too, but found
someone else had already done it.
// And you may have noticed a recent discussion regarding the
// difficulty of porting the A+ GUI.
yes, i have. which raises another question: how important do you
(plural, the readers here) consider the GUI to be? myself, i've
been having fun with just the command-line interpreter, and that
seems sufficient (that is, if i have an editor that'll cope with
the APL character set).
// I've heard of more than one [APL->C compiler]. As far as I
// know, they all exclude certain dynamic features of APL in
// order to be able to perform their compilation. Even if they
// were generally available and free (which I don't think any
// are), I would recommend becoming familiar with interpreted
// APLs (or J or K) first, 1) so you can see and evaluate the
// differences, and 2) because they offer much better learning
// environments.
that certainly sounds reasonable. i suppose really the APL->C
isn't really what i'm after anyway: i'm thinking about the
case where i want to run an APL program i've run on someone
else's computer. so is there an APL->machine code compiler? i
know APL's plenty fast as it is, but i'm more considering the
requirements of the execution environment.
: anothy;
Oscar Garcia
news:3B6C6293...@cosym.net...
> (reasonably) for things, A+ seems to be the only APL environment that
> gives out source, thus the only one i have any hope of running locally.
> are there others?
> finally (for now), i've heard about an APL->C compiler. pointers and
> oppinions appreciated.
>
The C source for the old APL that used to run in the IBM 1130 is here:
ftp://archive.uwaterloo.ca/languages/apl/apl-11
A somewhat massaged/tydied-up version of same, runs on Linux:
ftp://sunsite.unc.edu/pub/Linux/devel/lang/apl
A library of C functions implementing APL2, including an interpreter based
on them (I guess it might be also considered as a "semi-compiler"):
ftp://watserv1.uwaterloo.ca/languages/apl/CAP/index.html
There was also I-APL, which was ported to many early lowly microcomputers,
but don't know if the sources are available somewhere. If anybody knows I'd
be interested; I have been looking at alternatives for implementing some
sort of APL on a Palm PDA (don't laugh!)
David Ness
>
> There was also I-APL, which was ported to many early lowly microcomputers,
> but don't know if the sources are available somewhere. If anybody knows I'd
> be interested; I have been looking at alternatives for implementing some
> sort of APL on a Palm PDA (don't laugh!)
I doubt if anyone will laugh. J runs quite well on PocketPCs (a remarkably
complete implementation), and I ran both ancient J and APL 11 on my HP200
for years before I retired it. I now cam run APL11 on my iPAQ under DOS
emulation, but given I have access to `native' J, I don't, practically
speaking, ever bother...
Jim Lucas
>
> A library of C functions implementing APL2, including an interpreter based
> on them (I guess it might be also considered as a "semi-compiler"):
> ftp://watserv1.uwaterloo.ca/languages/apl/CAP/index.html
I suggest you be careful. What I saw at that link was about something I think
is called CAPLIB. I believe that APL2 is a registered trademark of an IBM
product. If what's at that web site isn't the IBM product, calling it APL2 is
breaking the law, no matter how good it is, or how good an imitation.
So, I suggest you be careful what you call things.
Friendly advice, /Jim
Roger Hui
195x
Ken Iverson and Eoin Whitney (Arthur Whitney's father)
were graduate students in math at Harvard.
196x
Ken Iverson left Harvard to join IBM.
1962
"A Programming Language" published.
1966
APL\360 implemented. The principals were Ken Iverson,
Adin Falkoff, Larry Breed, Dick Lathwell, and Roger Moore.
1966 4
I immigrated to Canada abroad the S.S. President Wilson
of the American President Lines. (APL, get it? :-)
197x
Arthur Whitney and I were undergraduates at the
University of Alberta.
1973
Arthur Whitney first worked for I.P. Sharp Associates (IPSA)
in Calgary as a summer student.
1974
I first worked for IPSA in Calgary as a summer student.
1978 4
Ken Iverson's "Operators and Functions" published. This became
the starting point for many extensions in the Sharp APL family
of dialects.
1980
Ken Iverson left IBM to join IPSA.
1983 1
Ken Iverson's "Rationalized APL" published. This is a
refinement and extension of the ideas in "Operators and
Functions", and evolved into "A Dictionary of APL".
1987 9
Ken Iverson's "A Dictionary of APL" published. It had gone
through many public drafts since about 1984.
1987 or 1988
Ken Iverson retired from IPSA.
1988
Arthur Whitney joined Morgan Stanley and designed and developed A
(having worked for others between IPSA and Morgan Stanley).
This evolved into A+ .
1989 or 1990
Eric Iverson founded Iverson Software Inc.
1989 8
I wrote the first line code (in C) for the J interpreter.
Quoting my book "An Implementation of J", Appendix A,
Incunabulum:
One summer weekend in 1989, Arthur Whitney visited
Ken Iverson at Kiln Farm and produced -- on one page
and in one afternoon -- an interpreter fragment on the
AT&T 3B1 computer. I studied this interpreter for about
a week for its organization and programming style;
and on Sunday, August 27, 1989, at about four o'clock
in the afternoon, wrote the first line of code that became
the implementation described in this document.
The language was named by accident when it became necessary to
save the source file for the first time, and j was the easiest
thing to type. (I am right handed.)
1990 4
Ken Iverson and I joined Iverson Software Inc.
1990 7
J first became publicly available as shareware at the APL90
conference in Copenhagen.
1993
Arthur Whitney left Morgan Stanley and designed and developed K.
Steven H. Rogers
>
> ... which raises another question: how important do you
> (plural, the readers here) consider the GUI to be? myself, i've
> been having fun with just the command-line interpreter, and that
> seems sufficient (that is, if i have an editor that'll cope with
> the APL character set).
>
the general user. For your own use, it depends. The A+ GUI is nice
for displaying graphs and plots. These can be saved in Postscript
format for publication. It would be nicer if they could be saved in
JPEG, PNG, SVG, etc.
I'm pretty happy with the command line myself. The A+ mode for
Xemacs is a productive environment for me.
Regards,
Steve
--
Steven H. Rogers, shro...@ionet.net -- I know if I quit drinking
and smoking and driving fast, I could add ten years to my life. The
problem is, I'd be adding them at the wrong end. - P.J. O'Rourke
Oscar Garcia
> ftp://archive.uwaterloo.ca/languages/apl/apl-11
Correction: It was probably an APL for the Digital PDP-11. If I remember
correctly, the other one was called APL\1130, from about the same time as
APL\360 and before C came about; most likely written in Assembler.
"Jim Lucas" <j...@danbbs.dk> wrote in message
news:vWnb7.1$yh....@news.get2net.dk...
> I suggest you be careful. What I saw at that link was about something I
think
> is called CAPLIB. I believe that APL2 is a registered trademark of an IBM
> product. If what's at that web site isn't the IBM product, calling it
APL2 is
> breaking the law, no matter how good it is, or how good an imitation.
>
Sincere thanks for the advice. As a recent arrival in North America I'm
used to a certain freedom of speech, and tend to forget the oppressive swarm
of lawyers always hanging over your head :-)
APL2 AND ANY OTHER TRADE MARKS THAT I MIGHT HAVE MENTIONED ARE THE PROPERTY
OF THEIR RESPECTIVE OWNERS. NO WARRANTIES EXPRESSED OR IMPLIED. USE AT
YOUR OWN RISK.
Anyway, the author says in the manual that CAPLIB2 "... is an
implementation of APL2 as documented in IBM publication SH21-1061-00, ...".
I certainly hope he is not right now rotting in jail!
Stanley Jordan
APL68000 Level II For power Mac
http://www.microapl.co.uk/
It's highly compatible with APL2.
With it, you can build object-oriented event-driven GUI-based Standalone Apps.
Up to 9 simultaneous threads (workspaces)
Very non-restrictive session manager, easy to work with.
It can easily call object code modules compiled from assembler, C, etc.
I have gotten some great use out of this feature.
For example I have added support for multi-media formats such
as MIDI and Quicktime.
(Array languages are great for multimedia programming.)
In short, I think it's roughly comparable to a good PC APL.
-Stanley Jordan
www.stanleyjordan.com
"Two ROMs don't make a write"
Anthony Sorace <ano...@cosym.net> wrote in message news:<3B6C6293...@cosym.net>...
Stanley Jordan
http://www.jsoftware.com/
I haven't tried this product yet, but I just wanted to let you know in
case you were looking at a variety of OS's.
-Stanley Jordan
www.stanleyjordan.com
Anthony Sorace <ano...@cosym.net> wrote in message news:<3B6C6293...@cosym.net>...
> about three years ago, a guy i worked with started telling me about how
> great APL was. intruiged, i did some reading of Iverson's old stuff and
> old IBM APL terminal documentation, but didn't think much of it, since
> even the guy who first told me about it seemed to think it was dead. i
> was quite pleased to find he was wrong (and so was he) when i picked up
> an A+ CD at UseNIX this June.
>
Thomas Affinito
> A personal idiosyncratic chronology:
...
> 1989 8
> I wrote the first line code (in C) for the J interpreter.
> Quoting my book "An Implementation of J", Appendix A,
> Incunabulum:
>
> One summer weekend in 1989, Arthur Whitney visited
> Ken Iverson at Kiln Farm and produced -- on one page
> and in one afternoon -- an interpreter fragment on the
> AT&T 3B1 computer. I studied this interpreter for about
> a week for its organization and programming style;
> and on Sunday, August 27, 1989, at about four o'clock
> in the afternoon, wrote the first line of code that became
> the implementation described in this document.
>
> The language was named by accident when it became necessary to
> save the source file for the first time, and j was the easiest
> thing to type. (I am right handed.)
>
Roger,
I seem to remember you posting this classic 1-pager in UseNet in the
early 90's...can't seem to find it electronically anymore and wondered
if you could post it again for us APL history buffs. (Maybe I'm
thinking of a 1-page C version for the J interpreter from way back
when, and not Arthur's code...in either case, I remember looking at it
and showing my grad schools friends...it definitely took us more than
a week to appreciate, and we certainly learned some fascinating macro
use from it!)
Tom
Roger Hui
> I seem to remember you posting this classic 1-pager in UseNet in the
> early 90's...can't seem to find it electronically anymore and wondered
> if you could post it again for us APL history buffs. (Maybe I'm
> thinking of a 1-page C version for the J interpreter from way back
> when, and not Arthur's code...in either case, I remember looking at it
> and showing my grad schools friends...it definitely took us more than
> a week to appreciate, and we certainly learned some fascinating macro
> use from it!)
It's been reposted as recently as this year. Anyway I
append it below.
Ken Iverson's advice "not to pamper our prejudices"
was never more true than in this case. My first reaction
on seeing the one page was, "Oooo [i.e. ugh], what is that?".
Ken suggested that I reserve judgment, but instead to persist
and study. I then did a very smart thing: I followed Ken's advice.
To really understand the one page, you have to have
experience in APL. For example, the verb arguments are
named a and w. Why a and w? It's short for alpha and omega,
well-known to aficionados of Ken Iverson's "direct definition".
Enjoy!
----------------------------------------------
From my book "An Implementation of J", Appendix A, Incunabulm:
One summer weekend in 1989, Arthur Whitney visited Ken Iverson at
Kiln Farm and produced -- on one page and in one afternoon --
an interpreter fragment on the AT&T 3B1 computer. I studied this
interpreter for about a week for its organization and programming style;
and on Sunday, August 27, 1989, at about four o'clock in the afternoon,
wrote the first line of code that became the implementation described
in this document.
Arthur's one-page interpreter fragment is as follows:
typedef char C;typedef long I;
typedef struct a{I t,r,d[3],p[2];}*A;
#define P printf
#define R return
#define V1(f) A f(w)A w;
#define V2(f) A f(a,w)A a,w;
#define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}
I *ma(n){R(I*)malloc(n*4);}mv(d,s,n)I *d,*s;{DO(n,d[i]=s[i]);}
tr(r,d)I *d;{I z=1;DO(r,z=z*d[i]);R z;}
A ga(t,r,d)I *d;{A z=(A)ma(5+tr(r,d));z->t=t,z->r=r,mv(z->d,d,r);
R z;}
V1(iota){I n=*w->p;A z=ga(0,1,&n);DO(n,z->p[i]=i);R z;}
V2(plus){I r=w->r,*d=w->d,n=tr(r,d);A z=ga(0,r,d);
DO(n,z->p[i]=a->p[i]+w->p[i]);R z;}
V2(from){I r=w->r-1,*d=w->d+1,n=tr(r,d);
A z=ga(w->t,r,d);mv(z->p,w->p+(n**a->p),n);R z;}
V1(box){A z=ga(1,0,0);*z->p=(I)w;R z;}
V2(cat){I an=tr(a->r,a->d),wn=tr(w->r,w->d),n=an+wn;
A z=ga(w->t,1,&n);mv(z->p,a->p,an);mv(z->p+an,w->p,wn);R z;}
V2(find){}
V2(rsh){I r=a->r?*a->d:1,n=tr(r,a->p),wn=tr(w->r,w->d);
A z=ga(w->t,r,a->p);mv(z->p,w->p,wn=n>wn?wn:n);
if(n-=wn)mv(z->p+wn,z->p,n);R z;}
V1(sha){A z=ga(0,1,&w->r);mv(z->p,w->d,w->r);R z;}
V1(id){R w;}V1(size){A z=ga(0,0,0);*z->p=w->r?*w->d:1;R z;}
pi(i){P("%d ",i);}nl(){P("\n");}
pr(w)A w;{I r=w->r,*d=w->d,n=tr(r,d);DO(r,pi(d[i]));nl();
if(w->t)DO(n,P("< ");pr(w->p[i]))else DO(n,pi(w->p[i]));nl();}
C vt[]="+{~<#,";
A(*vd[])()={0,plus,from,find,0,rsh,cat},
(*vm[])()={0,id,size,iota,box,sha,0};
I st[26]; qp(a){R a>='a'&&a<='z';}qv(a){R a<'a';}
A ex(e)I *e;{I a=*e;
if(qp(a)){if(e[1]=='=')R st[a-'a']=ex(e+2);a= st[ a-'a'];}
R qv(a)?(*vm[a])(ex(e+1)):e[1]?(*vd[e[1]])(a,ex(e+2)):(A)a;}
noun(c){A z;if(c<'0'||c>'9')R 0;z=ga(0,0,0);*z->p=c-'0';R z;}
verb(c){I i=0;for(;vt[i];)if(vt[i++]==c)R i;R 0;}
I *wd(s)C *s;{I a,n=strlen(s),*e=ma(n+1);C c;
DO(n,e[i]=(a=noun(c=s[i]))?a:(a=verb(c))?a:c);e[n]=0;R e;}
main(){C s[99];while(gets(s))pr(ex(wd(s)));}
Josef Sachs
> But Arthur had learned something from his Morgan Stanley experience,
> and the contract he negotiated with UBS was time-limited, after which
> he would be free to sell it openly. For this we are all grateful.
> (We will probably never know, but I wonder if the open availablility
for some value of "open"
> of K wasn't a significant factor in the eventual decision to release A+.)
Brian Redman could answer this definitively, but I'm reasonably certain
that nothing about K was a significant factor in the decision to release A+.
Jim Lucas
>
> > But Arthur had learned something from his Morgan Stanley experience,
> > and the contract he negotiated with UBS was time-limited, after which
> > he would be free to sell it openly. For this we are all grateful.
> > (We will probably never know, but I wonder if the open availablility
>
> for some value of "open"
Richard Stallman has said that the "free" in "free software" does not guarantee
that no money will be involved, rather that one is free to copy, inspect,
alter, and forward it.
Similarly, I didn't mean that K is "open source" (it's not), nor that one can
download it for free, but just that it is available on the open market. I know
there were people at Morgan Stanley who advocated that even back before A
became A+, but it seems that only recently did that concept receive the
necessary management support.
> > of K wasn't a significant factor in the eventual decision to release A+.)
>
> Brian Redman could answer this definitively, but I'm reasonably certain
> that nothing about K was a significant factor in the decision to release A+.
I have been assured that it certainly wasn't a conscious factor. I might say,
"That satisfies me," but that would be silly. I wasn't dissatisfied.
/Jim
Paul Chapman
[snip]
> Maybe someone else(s) could supply some history of other APL development
> efforts and their people
[snip]
Jim and others here will know me as the implementor of VIZ::APL and I-APL.
VIZ::APL
VIZ::APL was my idea. I'd done some commercial work for Cocking & Drury
using Sharp APL on their timesharing system from 1977-1980. I also used
APL/SV on the IBM 5100, which was a very expensive machine. Around that
time, various Intel 8080- and Zilog Z80-based CP/M machines were becoming
available (even in the UK). There were two APLs available for CP/M at that
time (the names of both of which I've sadly forgotten), both of which had
their drawbacks. I proposed to Geoffrey Roughton, for whom I'd worked in
1976 before going to college and with whom I'd later developed ZEAP, an
editor-assembler for the (4K!) NASCOM 1, that we try an APL for Z80 CP/M
machines. Geoffrey agreed to pay me a wage to write the code.
Work began in the middle of 1980. The implementation was done on a Cromemco
dual (8" I think) floppy machine with 64K RAM, later moving to a Superbrain
fitted with a (very expensive) 5Mb Winchester hard drive. The
implementation language was Zilog's Z80 Macro Assembler. The main design
goals were that it should be a full first-generation APL, and that it should
allow a virtual workspace of up to 1Mb, depending on available disk storage.
This was larger than workspaces available on most timesharing services at
the time. (VIZ = Virtual Single-user Z80.)
The virtual memory system swapped whole APL objects, which meant that an
individual object (eg array) had to fit in real memory. Parts of the
interpreter itself could also be swapped out (their virtual address pointed
back into the executable on disk), particularly the primitives and system
functions. Although the virtual memory code was incorporarted from the
start, it was the last thing to be tested. Astonishingly, when it was
"switched on" it worked immediately. At APL81, before release, someone
(someone here?) found a bug where arrays which had been changed through
indexed assignment were not marked as "dirty", which occasionally caused an
earlier, unmodified version to be reloaded from disk.
The implementation was based on Gillman & Rose and the APL\360 Reference
Manual (by?). I had never implemented a heap before. Didn't even know the
word "heap" (no LISP experience, see?). I didn't know "descriptor" either.
I therefore gave the data structures my own names, which were fruits
(punning on APL). Symbol table entries were "olives", object descriptors
were "grapes", heap objects were "plums" and empty heap spaces were
"prunes". The system used reference counting to avoid too much copying (an
innovation it took STSC a few more years to implement, I believe). It also
used genuine bit booleans and 64-bit IBM/360 floating-point emulation.
I remember coding all the scalar primitives in pencil on squared paper on a
trip to France, and then typing the code in to the (line) editor upon
returning. And shortly afterwards typing 2+2 to get 4. 2x2 gave 0, but
that problem was soon ironed out.
In 1981 I attended my first international APL conference in San Fransisco.
Dave and I showed an almost-finished version of VIZ::APL to a few (more)
bemused souls in my hotel room. We didn't exactly have a clue how to
promote.
A small London APL software house, Inner Product, then came on board and
helped promote and market the product from 1982-83. We took a booth at
APL82 in Heidelberg, and did a slightly better job of promotion. We sold
around a hundred copies (I don't remember the price).
I went to Australia for the first three months of 1983, again with
Geoffrey's financial assistance. I was supposed to be designing a 16-bit
product for the newly-arrived IBM PC. Dave Ziemann, an old schoolfriend and
fellow school Computer Club member, accompanied me to Boston and Toronto.
He introduced me to Dave Saunders, who had worked in IP Sharp's London
office, who in turn introduced us to Ken Iverson in Toronto. We were in
awe. He was bemused, I think, but gave us every encouragement. We did at
least get to see Niagara Falls.
I never did finish the 16-bit design (and I think I can justify that with
the hindsight of STSC APL*PLUS/PC's success). Upon my return I discovered
that Acorn Computers, makers of the BBC Micro (and later developers of the
ARM chip), had bought the rights to 1,500 copies for an amount that repaid
development costs and gave us a tidy profit. Acorn's management changed
shortly afterwards and the rebranded Acornsoft APL languished on a shelf,
never seeing the light of day.
Dave Saunders tried to revive VIZ::APL in 1984 and invited me to work for
his company Easi APL Systems Inc (like GNU, see?) in San Jose, CA. It was a
fun three months, but nothing came of it. But also working for Dave at that
time was an ex-Buddhist monk called Ed Cherlin.
I-APL
At APL86 in Machester, England, the very same Ed Cherlin got talking to
Anthony Camacho, then (and virtually perennially) secretary of the British
APL Association, and Ed Shaw. They were interested in getting APL into
schools. But APL interpreters for common schools machines (the BBC Micro in
the UK and the Apple II in the US) and teaching materials were non-existent.
These three good men approached me (at the welcome evening in Manchester
Town Hall, IIRC) with the idea of writing a freeware interpreter. I wasn't
crazy about writing another interpreter, but I didn't say no.
I-APL was formed shortly afterwards to develop an easily-ported interpreter
for small (8-bit, 32K) machines, together with printed teaching materials
and suitable workspaces. Anthony was UK chair, and Ed Cherlin US chair. We
raised initial funds from the British APL Association, which had made a
windfall profit from APL86. Work on the project was voluntary, but I ask to
be paid for the full-time implementation work.
Dave Ziemann was brought on board as a technical advisor, drawing on his
experience with the nascent APL standard. We wrote a short spec, which
included the requirement that the interpreter be standard-conforming.
Because of size restrictions, a first-generation APL was again settled upon.
The only APL-like extension added was "direct definition", an
unimplemented idea (of Ken's, as I have been reminded just now on this very
board by Roger Hui) allowing single line lambda-calculus-style function
definition using parameter names {alpha} and {omega}.
Work began on the interpreter in September 1986 on a 7.18MHz 8088-based PC
clone with 256K (later 512K) RAM. The interpreter itself was to be written
in a language to run on a virtual, 16-bit, stack-based machine. This
language, and an IDE in which to write code, were designed and written in a
month. The interpreter took about nine months to write. The draft standard
was followed very closely, and some of the algorithms in I-APL are lifted
rather literally from it. The most boring part was set to be implementing
floating-point arithmetic again, so I created a ittle fun for myself by
implementing BCD floating-point, with a one-byte exponent and a four-byte
mantissa. This had the advantage that 1'/.10 was exactly 0.1. Gene
McDonnell helped out with some of the transcendental functions.
The output of the IDE was an intermediate file which had to be "compiled" to
the final bytecode image of the interpreter. The compiler was written in
STSC APL*Plus/PC, and took five hours to run.
Parallel with the development of the interpreter, Linda Alvoord and Norman
Thomson collaborated to write an APL Tutorial to accompany the interpreter,
while Garry Helzer wrote an (encylopedic) APL encyclopedia. Tama Traberman
contributed the volume APL in Social Studies.
At APL97 in Dallas we presented our work in progress: a fairly complete
interpreter running (under emulation, of course) on an IBM PC. The project
received a great deal of support from the delegates and organizers, and we
added to our funds emormously thanks to the generosity of the APL community
(and especially one Jay N. Whipple III, whom I have never met). I remember
in particular (I think) Jim Brown of IBM giving an impromptu charity busk on
his guitar, a hat in front of him.
Work was finished in the fall of 1987. Porting I-APL involved writing a
small, native-code inner interpreter (what we would today call a Virtual
Machine). I-APL was ported to the IBM PC, the BBC Micro (by Tony Cheal),
the Apple II (by? I've forgotten -- does anyone know?), the Apple Mac (by Dr
Ian Clark), and a number of other machines. Technical porting instructions
were made publicly available, and even I do not know what other machines
(some in other countries) I-APL ended up running on.
I have in front of me copies of the various printed materials supplied with
I-APL translated into French, Finnish, Japanese and Russian. Other
translations may have been undertaken.
I-APL's main success, it has to be said, was in persuading the big
publishers to offer freeware or shareware versions of their own products.
When the PC became ubiquitous, these were probably more useful in education,
since I-APL was slow and provided a tiny workspace (although 32-bit versions
for the PC and ARM-based Acorn Archimedes were later developed with very
small changes to the IDE and the source code).
Cherers, Paul
Eric Landau
<cha...@corams.freeserve.co.uk> wrote:
|The implementation was based on Gillman & Rose and the APL\360 Reference
|Manual (by?)
Sandy Pakin, then with SRA.
Eric Landau, APL Solutions, Inc.
"Sacred cows make the tastiest hamburger." - Abbie Hoffman
lie...@us.ibm.com
I untangled the defines and macros and added some reasonable linefeeds and
indentation discovered the code is not nearly as complicated as it seems.
I'm sorry, but I don't think cryptic APL oneliners are impressive and I
don't think intensely dense C code is either.
Paper is cheap. What's the benefit of writing something on one page if it
makes it 10 times harder to read?
David Liebtag
David Ness
The answer to this is, of course, that `10 times harder to read' is a personal
statement, not an absolute truth independent of _who_ is doing the reading.
I found studying Roger's code to be _enormously_ fruitful and productive.
The very tersness attracted me to the central essence of the matters,
and forced me to `dig in' rather than to `read on'.
So I guess this is just another case where YMDV. So don't make the assumption that
just because paper _is_ cheap, it will profit _everyone_ if you use it.
Of course, I accept your testimony that more `space' would have been better for you.
Please accept mine (i.e. that it would have been worse for me).
Roger Hui
interpreter fragment posted to this forum recently.
Before I respond, I would like to take a look at your
reworked result. Can you please post that?
----- Original Message -----
From: "News Gateway" <owner...@sol.sun.csd.unb.ca>
To: <AP...@LISTSERV.UNB.CA>
Sent: Friday, August 10, 2001 11:59 AM
Subject: Re: Getting started
> X-From: lie...@us.ibm.com
lie...@us.ibm.com
Yes I was referring to Arthur's code you posted. I've posted the reworked
version below. I expanded some, but not all, the macros, renamed a few
things with longer names, and added some whitespace and linefeeds. Maybe
it was just my technique of reading it so I could get the gist of what was
going on. And maybe I'm alone in thinking it makes it easier to read; if
so, that's okay.
I don't claim to have explored all the code, but I feel like I left it in
a state where the density wasn't concealing (from me) the meaning.
David Liebtag
----------------------------------------------
From the book "An Implementation of J", Appendix A, Incunabulm:
One summer weekend in 1989, Arthur Whitney visited Ken Iverson at
Kiln Farm and produced -- on one page and in one afternoon --
an interpreter fragment on the AT&T 3B1 computer. long studied this
interpreter for about a week for its organization and programming style;
and on Sunday, August 27, 1989, at about four o'clock in the afternoon,
wrote the first line of code that became the implementation described
in this document.
Arthur's one-page interpreter fragment is as follows:
typedef struct a
{
long t;
long r;
long d[3];
long p[2];
}*A;
#define DO(n,x) {long i=0,_n=(n);for(;i<_n;++i){x;}}
long *malloclongs(count) {
return(long*)malloc(count*4);
}
movelongs(target,source,count) long *target,*source; {
DO(count,target[i]=source[i]);
}
tr(r,d)long *d;{
long z=1;
DO(r,z=z*d[i]);
return z;
}
A ga(t,r,d)long *d;{
A z=(A)malloclongs(5+tr(r,d));
z->t=t,z->r=r,movelongs(z->d,d,r);
return z;
}
A iota(w) A w;{
long n=*w->p;
A z=ga(0,1,&n);
DO(n,z->p[i]=i);
return z;
}
A plus(a,w) A a,w;{
long r=w->r,*d=w->d,n=tr(r,d);
A z=ga(0,r,d);
DO(n,z->p[i]=a->p[i]+w->p[i]);
return z;
}
A from(a,w) A a,w;{
long r=w->r-1,*d=w->d+1,n=tr(r,d);
A z=ga(w->t,r,d);
movelongs(z->p,w->p+(n**a->p),n);
return z;
}
A box(w) A w;{
A z=ga(1,0,0);
*z->p=(long)w;
return z;
}
A cat(a,w) A a,w;{
long an=tr(a->r,a->d),wn=tr(w->r,w->d),n=an+wn;
A z=ga(w->t,1,&n);
movelongs(z->p,a->p,an);
movelongs(z->p+an,w->p,wn);
return z;
}
A find(a,w) A a,w;{
}
A rsh(a,w) A a,w;{
long r=a->r ? *a->d : 1,n=tr(r,a->p),wn=tr(w->r,w->d);
A z=ga(w->t,r,a->p);
movelongs(z->p,w->p,wn=n>wn?wn:n);
if(n-=wn)
movelongs(z->p+wn,z->p,n);
return z;
}
A sha(w) A w;{
A z=ga(0,1,&w->r);
movelongs(z->p,w->d,w->r);
return z;
}
A id(w) A w;{
return w;
}
A size(w) A w;{
A z=ga(0,0,0);
*z->p=w->r ? *w->d : 1;
return z;
}
pi(i){
printf("%d ",i);
}
nl(){
printf("\n");
}
pr(w)A w;{
long r=w->r,*d=w->d,n=tr(r,d);
DO(r,pi(d[i]));
nl();
if(w->t)
DO(n,printf("< ");pr(w->p[i]))
else
DO(n,pi(w->p[i]));
nl();
}
char vt[]="+{~<#,";
A(*vd[])()={0,plus,from,find,0,rsh,cat},
(*vm[])()={0,id,size,iota,box,sha,0};
long st[26];
qp(a){
return a>='a'&&a<='z';
}
qv(a){
return a<'a';
}
A ex(e)long *e;{
long a=*e;
if(qp(a)){
if(e[1]=='=')
return st[a-'a']=ex(e+2);
a= st[ a-'a'];
}
return qv(a) ? (*vm[a])(ex(e+1)) : e[1] ? (*vd[e[1]])(a,ex(e+2)) : (A)a;
}
noun(c){
A z;
if(c<'0'||c>'9')
return 0;
z=ga(0,0,0);
*z->p=c-'0';
return z;
}
verb(c){
long i=0;
for(;vt[i];)
if(vt[i++]==c)
return i;
return 0;
}
long *wd(s)char *s;{
long a,n=strlen(s),*e=malloclongs(n+1);
char c;
DO(n,e[i]=(a=noun(c=s[i])) ? a : (a=verb(c)) ? a : c);
e[n]=0;
return e;
}
main(){
char s[99];
while(gets(s))
pr(ex(wd(s)));
}
Bob Cain
lie...@us.ibm.com wrote:
>
> And maybe I'm alone in thinking it makes it easier to read;
Not at all. The essential simplicity and the conventional nature of the
code that is evident in your expansion was totally obscured by the
original presentation.
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
////////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
To contribute your unused processor cycles to the fight against cancer:
To feed a hungry kid today at the cost of a click follow this link:
http://www.thehungersite.com/cgi-bin/WebObjects/HungerSite
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////
Roger Hui
one page interpreter fragment. The discussion is on
a C program, but is relevant to APL programs.
0. Paper may be cheap, but human (at least my) presentation
space is not, and is not going to get any cheaper.
The original code fits on one page; the reworked code
takes just under 3 pages. To me the there is a big
difference in going from 1 to 3.
Alan Perlis, talking about mathematical proofs, made an
assertion that is relevant here. A proof is more effective
if it is short enough that one can contemplate it while
lying in bed, out on a walk, or (especially :-) taking
a shower. The original 1-page and the density of code
contained therein, does that for me.
1. In all kinds of languages, frequently used words
tend to be short (Huffman coding at work). Again this
offers efficiency in a place where it's really important
-- my comprehension process at several levels (short words
are easier for my eyes to pick up; easier for my brain to
translate into meaning; etc.)
One of the things that the reworked code does, is to
remove the substitution of I for "long" and C for "char".
In the J interpreter, which uses this practice (I and C),
as of today there are 1794 occurrences (as a token) of I
and 611 occurrences of C, and similar order-of-magnitude
number of occurrences of other such short words.
2. The reworked code enforces the common C coding convention
of one statement per line. Strict enforcement of this
convention misses opportunity to display "micro structure"
in the code. For example, from the J interpreter:
an=AN(a); ar=AR(a); as=AS(a); at=an?AT(a):B01;
wn=AN(w); wr=AR(w); ws=AS(w); wt=wn?AT(w):B01;
I can tell at a glance that similar things are being
done on a and w. However, with one statement per line:
an=AN(a);
ar=AR(a);
as=AS(a);
at=an?AT(a):B01;
wn=AN(w);
wr=AR(w);
ws=AS(w);
wt=wn?AT(w):B01;
It take more effort, and there is more opportunity
for error.
One statement per line also uses more volume for things
that are simple and therefore don't deserve volume.
For example, the function iota:
Original:
V1(iota){I n=*w->p;A z=ga(0,1,&n);DO(n,z->p[i]=i);R z;}
Reworked:
A iota(w) A w;{
long n=*w->p;
A z=ga(0,1,&n);
DO(n,z->p[i]=i);
return z;
}
Well, I myself would have put a blank between a semicolon
and the following statement, thus:
V1(iota){I n=*w->p;A z=ga(0,1,&n); DO(n,z->p[i]=i); R z;}
3. The reworked code removed the macros V1 and V2, among
others. It's probably difficult to tell just how important
these macros are; after all, V1 and V2 are very simple
(I include the typedef of A to make it make more sense):
typedef struct a{I t,r,d[3],p[2];}*A;
#define V1(f) A f(w)A w;
#define V2(f) A f(a,w)A a,w;
But consider:
a. A defines the APL array type. V1 and V2 define verbs
that take one or two array arguments and return an array result.
Seen them before? They define APL functions. So as soon as
I see V1(iota) (as above), I know it's an APL function, and all
that that entails. "A iota(w) A w;" is not as easy (esp. if
you repeat the pattern several hundred times). Many errors
in programming occur in the interface, thus V1 and V2 are used
in a particularly sensitive spot, in the interface between
functions.
b. The J interpreter has 734 occurrences of the equivalent
of V1 and 343 occurrences V2 (among other similar
function definition macros). Such use represents a
large amount of suppression of detail.
c. There was at least one occasion when I need to to
add an extra argument to the V1/V2 functions. With the
macros it was a cinch.
-----------------------------
I won't go on. I hope I have said enough to indicate that
there is more to Arthur's one page than meets the eye.
I said in the preamble that I studied it for a week for
its organization and programming style. There is definitely
enough organization and style in the one page to provide a
firm foundation on which to build an APL interpreter.
Background:
- I had never seen, then or since, the source code for any
other APL interpreter (well, other than the J interpreter).
- I have never had any discussion with Arthur on the one page,
so any misinterpretation of his ideas/style are my own.
Bob Armstrong
Your note and this thread are such excellent background that I am
adding a link to it on http://CoSy.com/K/CoSy.htm .
"Jim Lucas" <j...@danbbs.dk> wrote in message news:
<0w7b7.41$TY5...@news.get2net.dk>...
> K did not really
> "evolve from" A, though the basic ideas of K almost certainly began to evolve
> in Arthur's mind during the years of his work on A/A+, if not before.
>
> Several of those principles are quite different from those of A/A+/APL (and J).
> These include lists (and lists of lists) rather than arrays of arbitrary rank
> as the fundamental data structure, consistent extension of bracket-semicolon
> notation, unlimited argument valence, limitation of infix notation to primitive
> functions, projection, etc. I believe it was at APL93 in Toronto that he
> showed me on a notebook computer his first tentative implementation of K and
> explained to me some of the thinking behind it.
Note , valence is unlimited but fixed . A function knows how many arguments
it has and if any are missing , becomes a projection upon those .
-- Bob Armstrong -- http://CoSy.com -- 212-285-1864
Charter subscriptions now available :
K.CoSy eXtreme Computing Environment