⍝ The second APL thread

This is the second APL thread, albeit a bit premature. This is a thread for discussing everything related to APL, including related languages such as J and K. There are a number of other APL users and interested others here, so I'll start with some questions: What initially drew you to APL? What do you use APL for? Which implementation do you use? Which function or operator is your favorite? What do you like and dislike about APL? How do you write APL? Do you have a special keyboard? What of the rest of your environment? Do you believe APL will last for many more decades or not; why? What do you believe mainly differentiates APL from other languages?

APL is a beautiful language. Too bad it's hardly available anywhere. I know of only two implementations, and both are available just in a handful operating systems (debian and windows, usually) and hard to port. One of them is proprietary so porting isn't an option, and the other one is GNU so I am afraid just to look at it and have to figure out that 'configure' scheme that GNU uses. I wish there was a portable APL open source system out there, or maybe there is something that I haven't found yet?

I think APL missed its opportunity to be a popular language as it would have been the perfect shell language on personal computers back in the late 70s and 80s to replace BASIC's unfortunate dominance. Its a compact yet powerful language that would have worked well in the tiny memory spaces of personal computers back then. I am having trouble getting fonts to work with GNU APL, I think it only works with the emacs APL plugin. If anyone could explain how to get the fonts to work on Linux I would appreciate it. There is a company called Gemesys that has ported a bunch of old APL implementations to Android. Here is APL2 from the original source that ran on IBM mainframes: https://play.google.com/store/apps/details?id=org.gemesys.android.tryapl2&hl=en And here is an Android keyboard with APL fonts https://play.google.com/store/apps/details?id=gemesys.keybrd

I'll need to resubmit some little programs and other things I've written, but that's no matter, and I've new thoughts as well. Here's a simple definition of e that gains accuracy with higher values of n: e←+/÷!(-⎕IO)+⍳n My GNU APL signals DOMAIN ERROR for n higher than 171. All it does is get all numbers from ⎕IO to n or one less than n; adds the negation of ⎕IO to these to ensure the series begins from zero, as adding zero changes naught and adding negative one subtracts one from each; gets the factorial of each of these; gets the reciprocal of these factorials; and then sums them to reach e. I'm still using APL 1.6 and ↑⍳100000000000 now results in a segmentation fault. As I pointed out last thread, it's obvious that APL depends upon recognizing idioms for optimization. That expression need not create an entire array, as first will simply return ⎕IO, the first thingy, or zero for numerical arrays; iota will always return an array unless passed zero. I'm not certain of the Dyalog APL implementation strategy, but it seems clear that a sufficiently large APL array should simply store itself in a representation so elements can be generated as needed. With sufficiently large arguments to iota, the array could be represented by a program to return the element; this program would simply be + with an external index check. My original thinking involved compiled representations for these programs, but that doesn't allow for easy modification. An iota array with a constant added to it, say six, could be represented as 6++ when an element is wanted. Even something such as ⍳100000000000+⍳100000000000 could be represented easily as ⍳100000000000++ and the other iota would decompose similarly. This doesn't even require much modification to arrays, as they'd simply store APL programs in some cases, transparently. >>136 I've been in a discussion with someone who successfully compiled GNU APL on OpenBSD. Apparently, all that was missing was to symlink the native libtool and add one define for memory limits that was needed. >>199 >I think APL missed its opportunity to be a popular language as it would have been the perfect shell language on personal computers back in the late 70s and 80s to replace BASIC's unfortunate dominance. Its a compact yet powerful language that would have worked well in the tiny memory spaces of personal computers back then. I'd say Forth had a better chance than APL, but this is just speculation. >I am having trouble getting fonts to work with GNU APL, I think it only works with the emacs APL plugin. If anyone could explain how to get the fonts to work on Linux I would appreciate it. I have no problems with a default xterm, but I almost exclusively use it with the gnu-apl-mode. Since the APL character set is in Unicode, you should simply need to have a Unicode font, which should already be done for you.

>>410 >I'd say Forth had a better chance than APL, but this is just speculation. Forth had a better chance only because its a simpler langauge to implement and it gives direct access to hardware which are both good things on simple computers back then with barebones operating systems where a program to total control of a computer and accessed hardware directly. But stack juggling gets old fast and writing all those dups and swaps in your code is just not practical for general purpose programming.

How can a beginner programmer learn some APL? Are there any good introductory books? I've only read one programming book so far, a Common Lisp one.

>>1250 This is so far the only good introductory book on APL I've found https://www.dyalog.com/uploads/documents/MasteringDyalogAPL.pdf

>>1250 >How can a beginner programmer learn some APL? Are there any good introductory books? I've only read one programming book so far, a Common Lisp one. I've found that ``APL An Interactive Approach Third Edition'' is a good work to start with. I then recommend reading ISO 13751, the ISO APL standard. That can be found here: www.math.uwaterloo.ca/~ljdickey/apl-rep/docs/is13751.pdf This is actually a gzipped archive, despite the name, just to save you some frustration. The ISO standard can be difficult to read if you don't already have an idea of what APL is and what many of the functions do, so you should read these in the order I've provided them, although I suppose reading them in tandem could also work.

I find this single page J interpreter to be fascinating: 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)));} It shows how easy it is to implement one of these languages if certain considerations are disregarded. I'm not aware of any small APL interpreters, but I feel inspired to begin the journey of writing my own. Unlike as with Forth in which it's encouraged to implement the language oneself, I don't particularly notice this with the APL family of languages. What do you find of this? Does it seem justified or not?

If I want to go with FOSS implementations, is APL or J better?

>>3000 Since you are concerned with your software freedoms I think it would please Dr Richard Stallman if you used his GNU APL implementation. There are no free as in freedom implementations of J

>>3003 >There are no free as in freedom implementations of J But what's this then? >J Source can be used under GNU General Public License version 3, in which case the terms and conditions of that license apply.

>>3006 whoops, sry, I thought since that J was developed by a company it was proprietary

A few more array-oriented languages that I know of: co-dfns [0]: a highly parallel compiler for functional, lexically-scoped APL, targeting CPUs and GPUs. Affero GPL 3. Currently depends on a copy of Dyalog APL, but will eventually be self-hosting. klong [1]: An near-exact clone of K, but with a few changes to the grammar to make it less ambiguous. Public domain. [0] https://github.com/arcfide/Co-dfns [1] http://t3x.org/klong/index.html

>>3019 A compiler under the AGPL? That's interesting. Is there an expectation it'll be used as a service or is that just future proofing for cloud compilers?

>>3019 The C-code of co-dfns is truly written like an APL programmer... Maybe I just don't understand these paradigms, but the code doesn't seem very easy to read to me.

>>3023 In one of his interviews, Aaron Hsu says that he optimizes *very* strongly for having as few characters of code as possible. That way, he can fit as much stuff onto the screen as possible, and cross-reference things very quickly. Also, it makes him feel better about throwing code away. If he reads some of his old code and doesn't understand it, then he can throw it away; it's only a few lines. Then, he rewrites the new version to be shorter. He does this *a lot*. Just look at the "Contributors" section of the github repo - he's added 4,068,543 lines of code and removed 3,759,018.

So, what's something that you've written in APL recently? What's a reason you didn't use APL for something? I've wanted to use APL for several projects, but it always seems to fall short in some way, when it would otherwise be particularly suited to the program. As an example, I almost chose to use APL to write an interactive tool with, but APL has no character-granular input and this was a necessary feature I didn't want to hack around.

I always get a kick out of this video. It shows off the kind of things you can do with a language that's in tune with its domain.