Lambda the Ultimate

In breezing through some articles, I did run across a criticism of APL from Guy Steele in his article On Growing a Language. Ok, so he's biased because he likes the open ended extensibility of Scheme but his argument is that end users can't extend the dictionary of glyphs - thus providing a discontinuity between the primitives defined by the language implementor and the functionality added by the end user.

I was kind of wondering whether J had addressed this concern. Here's the full quote from Steele:

APL was designed by one man, a smart man - and I love APL - but it had a flaw that I think has all but killed it: there was no way for a user to grow the language in a smooth way. In most languages, a user can define at least some new words to stand for other pieces of code that can then be called, in such a way that the new words look like primitives. In this way the user can build a larger language to meet his needs. But in APL, new words defined by the user do not look like language primitives at all. The name of a piece of user code is a word, but things that are built in are named by strange glyphs. To add what look like new primitives, to keep the feel of the language, takes a real hacker and a ton of work. This has stopped users from helping to grow the language. APL has grown some, but the real work has been done by just the few programmers that have the source code. If a user adds to APL, and what he added seems good to the hackers in charge of the language, they might then make it be built in, but code to use it would not look the same; the user would have to change his code to a new form, because in APL a use of what is built in does not look at all like a call to user code.

However the gains in expressiveness of the language are huge.

I'm not trying to be difficult - I see your point (and I feel similarly about APL, although this time round it started to make a bit more sense - I guess it's a war of attrition) - it's just that I can still remember the shock when I learnt Lisp macros and found that I could do "anything".

The APL philosophy is very different than that of most other programming languages. One point of view is to say that APL requires you to think using linear algebra (matrices etc.). You apply that language (lin alg) to various problems, using APL as an executable notation. In this sense it is not a general programming language... It dictates its own way of doing things very strongly. Much more so than most other languages.

However, to be fair to APL, all programming languages impose a grammar on names and all languages I am familiar with forbid names that do not agree with the grammar. How else could you even define what a name is in a programming language?

Also, most languages have a limited set of glyphs that we don't always think of as names, + - / et cetera. In Java Basic, and so forth such names are few in number and we over look them -- with APL, where the glyphs number almost 200, the glyphs dominate and the discrepancy between primitive name syntax and defined names is apparent.

In some languages, that allow operator overloading, you can redefine glyphs like + but it's interesting that the consenus on overloading is that it's generally a bad idea. It converts standard symbols, willy nilly, into non-standard meanings which greatly complicate reading code in any language. APL wisely forbid this right from the start.

I never felt this is the consensus. Actualy overloading ( of routine names in general, not just operators) is quite popular (Ada, C++ etc.). What people shy away from is the ability to change the precedence and associativity of operators (like you can do in Prolog). This is understandable, as this causes trouble for parsers. It is also, naturaly, bad for readability.

. there IS a way for a user to grow the language in a smooth way: it is called "FUNCTION DEFINITION." Only a "glyph snob" would consider A + B to be fundamentally different from A PLUS B.

. The difference in APL philosopy is not primarily due to it's linear algebraic bent. It starts with the use of adverbs/operators, which redefine verbs.

. Glyphs are ALREADY overloaded, at least for the mathematical operations, where internal data representations define the code that is actually used for the various operations.

. The language fascism not only a property of APL, but also of Perl, which until recently, was a single person's whim.

Is the APL table fairly representative of APL symbols? I'm aware that there may be differences across APL vendors, but most of the discrepancies seemed to be the problem of how to enter the characters from an ASCII keyboard - not the symbols themselves.

Also, is there any material that gives a comparison of the J vocabulary with the APL symbols? Thinking about putting something together myself, but if someone's already done it I don't see a need to reinvent. Ok, so I'm aware that J is quite different in it's usage. Still, I'd kind of like to see a chart that shows the similar operations (even if they are not identical in semantics).

Thanks.

Here'sa mild stab at mapping APL2 Symbols to J Vocabulary.

Let me know of any obvious mistakes (and if you can fill in the gaps that would also be helpful).

Thanks.

[I think this time I'm replying on a sub-thread (by clicking on the cow skull after a post) - let's see what happens...] [Nope. Still gets placed at the end of the page. OK, this reply was in response to Ehud saying he didn't understand my comment about BASIC...]

Some untruths: . APL was not designed by one man.

The point, though, that Steele is trying to make is that the control of the notation is in the hands of the few - as opposed to the masses. The types of things users do with languages is usually well beyond the visions of the original language designers. In order for a language to evolve into a general purpose language, it should be extensible to fit the needs of a multitude of niche applications.

That said, I personally like languages that reflect the vision of a single person. IMHO, C++ was a better language prior to being turned over to a standards committee.

. there IS a way for a user to grow the language in a smooth way: it is called "FUNCTION DEFINITION." Only a "glyph snob" would consider A + B to be fundamentally different from A PLUS B.

My belief is that the notation certainly influences the readability and writeability (sometimes for the better, sometimes for the worse). But I don't think that shorthand notation is where the languages derive their power. Instead, I'd point to the higher level data structures (arrays, matrices, tables, etc) and the ability to manipulate them in a much more concise manner than any other language (at least as fluidly). I'll get to verb/adverb combinatorials below.

But if you consider glyphs to be more than syntactic sugar and a fundamental character of the languages, then it's important to consider how those symbols evolve over time.

. The difference in APL philosopy is not primarily due to it's linear algebraic bent. It starts with the use of adverbs/operators, which redefine verbs.

In my mind, the terminology of redefining verbs through adverbs is parallel to the Higher Order Functions in the FP languages (ML, Haskell, etc). What they seem to represent is functions that operate on other functions, similar to the idea of Map and Fold, etc...

. Glyphs are ALREADY overloaded, at least for the mathematical operations, where internal data representations define the code that is actually used for the various operations.

. The language fascism not only a property of APL, but also of Perl, which until recently, was a single person's whim.

I personally believe that language designers (Steele, Iverson, Wall, Wirth, Stroustrap, etc) are quite reasonable and responsible with their caretaker positions over their respective languages. But at the top level of design, all decisions come with tradeoffs in orthoganility, expressiveness and complexity. Some designers, like Wirth, err on the side of simplicity. Other designers, like Stroustrap, err on the side of complexity.

It didn't harm BASIC (which had "call" IIRC)! And many (most imperative?) languages still have a separation between "control" and procedure syntax, with only procedures extendable.

The person who wrote this, Arthur Whitney, has a language that competes with J, called K. since starting to learn K about 4 months ago, I have not touched another language,

the next K version is on the horizon (check the archives for K4), and i cannot wait.

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=3D0,_n=3D(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]=3Ds[i]);} tr(r,d)I *d;{I z=3D1;DO(r,z=3Dz*d[i]);R z;} A ga(t,r,d)I *d;{A z=3D(A)ma(5+tr(r,d));z->t=3Dt,z->r=3Dr,mv(z->d,d,r); R z;} V1(iota){I n=3D*w->p;A z=3Dga(0,1,&n);DO(n,z->p[i]=3Di);R z;} V2(plus){I r=3Dw->r,*d=3Dw->d,n=3Dtr(r,d);A z=3Dga(0,r,d); DO(n,z->p[i]=3Da->p[i]+w->p[i]);R z;} V2(from){I r=3Dw->r-1,*d=3Dw->d+1,n=3Dtr(r,d); A z=3Dga(w->t,r,d);mv(z->p,w->p+(n**a->p),n);R z;} V1(box){A z=3Dga(1,0,0);*z->p=3D(I)w;R z;} V2(cat){I an=3Dtr(a->r,a->d),wn=3Dtr(w->r,w->d),n=3Dan+wn; A z=3Dga(w->t,1,&n);mv(z->p,a->p,an);mv(z->p+an,w->p,wn);R z;} V2(find)true V2(rsh){I r=3Da->r?*a->d:1,n=3Dtr(r,a->p),wn=3Dtr(w->r,w->d); A z=3Dga(w->t,r,a->p);mv(z->p,w->p,wn=3Dn>wn?wn:n); if(n-=3Dwn)mv(z->p+wn,z->p,n);R z;} V1(sha){A z=3Dga(0,1,&w->r);mv(z->p,w->d,w->r);R z;} V1(id){R w;}V1(size){A z=3Dga(0,0,0);*z->p=3Dw->r?*w->d:1;R z;} pi(i){P("%d ",i);}nl(){P("\n");} pr(w)A w;{I r=3Dw->r,*d=3Dw->d,n=3Dtr(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[]=3D"+{~<#,"; A(*vd[])()=3D{0,plus,from,find,0,rsh,cat}, (*vm[])()=3D{0,id,size,iota,box,sha,0}; I st[26]; qp(a){R a>=3D'a'&&a<=3D'z';}qv(a){R a<'a';} A ex(e)I *e;{I a=3D*e; if(qp(a)){if(e[1]=3D=3D'=3D')R st[a-'a']=3Dex(e+2);a=3D 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=3Dga(0,0,0);*z->p=3Dc-'0';R z;} verb(c){I i=3D0;for(;vt[i];)if(vt[i++]=3D=3Dc)R i;R 0;} I *wd(s)C *s;{I a,n=3Dstrlen(s),*e=3Dma(n+1);C c; DO(n,e[i]=3D(a=3Dnoun(c=3Ds[i]))?a:(a=3Dverb(c))?a:c);e[n]=3D0;R e;}

main(){C s[99];while(gets(s))pr(ex(wd(s)));}

About the the only thing that pops out at me is that it looks like it has static type checking built in. I marked off the K Technical Material page a while back when I was reading the J manuals, but haven't spent the time reading thru them. The user and reference manuals are there for anyone interested in exploring the language. (Note: for some reason the link comes up on the Kdb frame. To get to the K documentation, just click on the K on the left hand frame).

Do I gather that you had experience in either APL or J before diving into K? And while we're at it, what is there specifically about the language that makes it useful from your domain?