It took us over 300 emails (many of them long), and several emails, all over the course of many months to design the system. I think it turned out very well.
= doesn't matter for obvious reasons. TAO was not applied to < etc. because it isn't very meaningful on scalars, and it'd be confusing behaviour. It thus applies to โโโธ.
Oh, yes, I added the extension, but again, it isn't very useful.
Actually, now we're discussing language theory, โก is a more fundamental function than = since = can be defined in terms of โก but not vice-versa. = is simply โกโฅ0.
So one of the ideas I have for a redone APL is to get rid of all the scalar functions and replace them with "big" functions, since the scalar functionality can be accessed with fโฅ0
That'd make a kind of RISC APL.
Here's another one: × could mean +.× since × is simply +.×โฅ0 which would allow matrix multiplication as A×B.
Also, this could get rid of all the "axis pairs" like /โฟ and ,โช and โฝโ since the last axis function can be expressed in terms of the first function โค1.
Similarly, the various set functions could be made progressive (without replacement), since โค0 โ or โคโ 0 would give you the current definitions.
While interesting in principle, actual practical code would be littered with โค and โฅ everywhere, and the right operand would often clash with the right argument, requiring lots of โข or parentheses.
Of course, one of the things I'd straighten out if I could start over, would be enforcing that โบ f dop g โต should always be the same as โบ f dop (โบ g โต)โขโต, so one could use braces like in Xโค{0 โ}Y.
Also, common construct like โฅ0 and โค0 โ might be convenient to name (Perv, EachLeft) which would also avoid the operand-argument clash.
An interesting one is dyadic โฝ/โ which are very often handy in code golf. Hover, they can't address multiple axes at once like dyadic โ and โ can. If โฝ and โ had been designed like โ and โ, the current definitions would have just been โค0 1/โค0 ¯1
@voidhawk Good. Your code's performance may also have improved. J doesn't even have ¨ but it does have the general L: which I understand was just now changed to match my definition for โฅ. So ¨ is simply โฅ¯1.
Speaking of performance, how does rank work internally? If I have something like 1 2 3+โค1โข3 3โดโณ9, does it expand the left argument to the shape of the right argument and do matrix addition or?
I noticed some interesting behavior if I wrote functions that have side effects if I try and use them with the rank operator rather than ¨โ
@voidhawk Many cases of rank are special cased. Certainly all scalar dyadics. I don't think it needs to duplicate the data, but rather it can instruct the CPU to stride in clever ways.
By the way, looking at this code, is there a more elegant way to get a 3-column matrix from a vector of indeterminate length than {(3÷โจโขโต)3โดโต}?
@Bubbler Actually, I kind of disagree. If โค and ¨ and / etc. weren't forced to a specific order, they could run faster, including by taking advantage of multi-threading.
@voidhawk No, but if you use my extensions, that's ¯1 3โดโต or in dzaima/APL it is โฌ3โดโต
@voidhawk Not really. There are a limited number of primtives, and only very few have side effects. The system functions can at least be classified as "safe" and "potentially unsafe" even if there will be some false "unsafe"s.
If only โ had been a {โ} function you could do โขโ to read from stdin, process then output.
@voidhawk Yeah, that one too. It is a young addition to the family, so I forgot about it.
@Bubbler The inverse is obviously โNPUT. While not safe for multi-threading, the idea is that you can apply a function directly to a filename with the effect of processing the modifying the content. E.g. โฝโขโNGET would reverse the file content.
And โฝโข(โNGET 1,โจโ) should reverse the lines in the file.
I remember reading jayfoad's AoC 2018 solutions last year when I was getting into APL and being unable to use them since โNGET wasn't in the free-to-download 14.x(?) interpreter
@voidhawk Yeah, there isn't much new in 17.1 but the access to APL has definitely improved. And then 18.0 has been developed in parallel, so there's just so much amazing coming in 18.0โฆ
Yeah, one thing that bothers me with โR is that it isn't even single-thread safe when reading from and writing to the same file. It should detect that the same file is used for input and output and write to a temporary file, then rename.
Yeah, โข gives all kinds of possibilities because you know what happens next, and can have a direct connection across. That's why โขโ and โข, can work even though โ and , have no inverses.
OK. The idea is that if we have a sequence of functions with no array on the far right, then they instead derive a new function according to a clever scheme. If there are only two functions, then the left function is applied monadically to the result of the right function (which may be monadic or dyadic depending on the arguments outside):
At first, it can be rather difficult to parse such dense things (we call them function trains, or just trains). It helps to add spaces and/or parentheses.
Just output the function without giving it any argument.
Ah, so then we start from the right and group the rightmost three. They form a new derived function as we've seen.
So e.g. - โข ~ โ.×โจ becomes - (โข ~ โ.×โจ) but we already know how a 2-train works.
And if there are five, we do the same โ/ - (โข ~ โ.×โจ) where โ/ is applied to the argument and (โข ~ โ.×โจ) is applied to the argument, and the results are subtracted.
@Adám For some reason I find this explanation of trains and tacit more clear than the chat lesson. I think it's the examples. In any case, this is yet the third time I'm trying to understand this. I hope it sticks.
@EdgyNerd Yes. But you kind of have to know that if you multiply or divide a negative number by a positive number, the result is negative, and if you use two positive numbers, the result is positive.
And then of course you're quite right on track that just dividing a number by itself gives 1.
