On Wed, 2008-01-09 at 18:52 -0500, Raul Miller wrote: > On 1/9/08, Robert Bernecky <[EMAIL PROTECTED]> wrote: > > The ISO standard was intended to enshrine existing behavior, > > when most or all implementations had the same behavior, so > > we did not have much wiggle room here. > > Which seems like a good reason to switch from APL to J, > for new code. (Not that installed base ever goes away...) >
Correct. Ken and I had many ongoing battles over language, mostly semantics. He wanted, for example, to change the definition of monadic iota to make it an odometer function. Unfortunately, this would have broken every occurrence of "iota rho vector" in client apps, because the result rank would be 2 instead of 1. Similar things happened after I introduced the rank conjunction into SHARP APL, at which time he wanted to kill off the anomalous axis-bracket notation used in catenate, reduce, scan, etc. Ditto with []IO. All good ideas, but the merchant bankers, actuaries, and manufacturers who were our user base would have killed us. And so on.... Eventually, after repeated cases of this sort of thing, I convinced Ken that changes to SHARP APL had to be, by and large, limited to "conforming extensions" -- taking an error and making it produce a result, such as when we extended AND and OR to non-Boolean arguments, because our user base was too large and had too many big sticks to beat on us with. I told him a fresh start was the only was to go for these various well-deserved, but incompatible language changes, and that avoiding the APL keyboard/transmission code problems was critical for user acceptance. Another reason for a fresh start was that the SHARP APL mainframe interpreter was written in assembler code, so any changes to it were tedious. Furthermore, some internal data structures had hard limitations that would been nightmarish to change, which is why, for example, the mainframe never supported user-defined and derived functions as operands to adverbs and conjunctions. As for the installed user base problem, the SAC approach appeals to me: Implement a minimal core language, then define every other language (e.g., structural verbs - transpose, rotate, reverse, reshape...) in terms of that core, placing those definitions in a standard library or include library. This approach offers several advantages to the all concerned: - non-conforming changes, such as the iota change above, can be implemented by adding a NEW member to a library, or by releasing a new library with a different name. The installed user base can convert apps to the new semantics at their leisure, or not at all, as they wish. - strong optimizations give the library code and user-defined code the same power. - if you don't like the distributed version of, say, iota, you can just change the definition of it in your library. At your own peril, of course, if you use other people's code and want it to work. - SAC also lets a user define new types, at no cost in run-time efficiency, so you are not chained to the design decisions of the language implementer. Bob ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
