Backward compatibility can be a very very limiting factor. When I took over IC/1 it was supporting several older APL versions. That was basically because ADRS, ADI and FPS were incorporated into IC/1 unchanged. So even if IC/1 should be an APL2 application and be based on APE. Not only were we talking about VSAPL, APLSV and such but also tests for old versions of TSO and VM plus a very limiting old subset of GDDM.
At the same time as we were cleaning up old problems in the underlying products that made up IC/1 I did some experiments with creating IC/e - called Black Box at the time. Cleaning up so as it only supported the newest of everything cleaned away 90% of the code. Once the limitations of the old was gone it was relatively easy to put in new functionality. Another thing to note is that adding new functionality in the code was very simple compared to all the documentation that was needed with it. 2008/1/10, Robert Bernecky <[EMAIL PROTECTED]>: > > > 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 > -- Björn Helgason, Verkfræðingur Fugl&Fiskur ehf, Þerneyjarsund 23, Box 127 801 Grímsnes ,t-póst: [EMAIL PROTECTED] Skype: gosiminn, gsm: +3546985532 Landslags og skrúðgarðagerð, gröfuþjónusta http://groups.google.com/group/J-Programming Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans góður kennari getur stigið á tær án þess að glansinn fari af skónum /|_ .-----------------------------------. ,' .\ / | Með léttri lund verður | ,--' _,' | Dagurinn í dag | / / | Enn betri en gærdagurinn | ( -. | `-----------------------------------' | ) | (\_ _/) (`-. '--.) (='.'=) `. )----' (")_(")
---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
