Elijah -
I do not agree, as far as QuadIO goes:

When I was supporting APL for JHU/APL (where we had hundreds of APL users), I heard many arguments (often very loud arguments) for QuadIO being hard-set to1, and just as many, for it being hard-set to 0. All of the public utility code we wrote was
required to be QuadIO independent, or to localize or restore QuadIO settings. This became a natural approach, and I continued to write my code as QuadIO-independent, until reprimanded at various APL shops (as I remember it, the first required 1, the
second 0).

On the other hand, in these decades, most of the programming world at large is probably use to QuadIO=0 (which I, personally, prefer): In the 70s and 80s, many of us had started with Fortran 2 or 4 (implicit QuadIO=1).

When I taught APL to other-language programmers (prospective converts), I would set or default QuadIO to 0, and then mention that 1 was also an option.

Dave

n Monday, November 16, 2020 at 2:31:15 AM UTC-5, Elijah Stone wrote:

On Thu, 12 Nov 2020, J. Clarke wrote:

This is kind of the old story. When there's more than one way to do something and no sound reason to prefer one over the other, let the user or the developer decide. We do it with quad-IO, why not with the branch directions on complex calculations?

FWIW I have always thought ⎕io was not a great idea. Most people I have spoken to on the matter feel similarly.

Any publication on APL needs to specify whether it has ⎕io as 1 or 0. (Or do the trick where you add/subtract ⎕io to/from indices, which is if anything even worse.) It bifurcates the language and makes it harder to reason about as a unity.

If you need a trig function with branch cut that goes the other way,
define one inline. It's a fairly niche use-case, and not a particularly burdensome definition; and it alleviates the main language of overloads.

-E

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)