Backwards compatibility

From APL Wiki
Revision as of 20:41, 23 October 2020 by Marshall (talk | contribs) (Created page with "In APL design, '''backwards compatibility''' is the practice of ensuring that older codebases or systems are able to work with new APL dialects, versions, or libraries. Since...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

In APL design, backwards compatibility is the practice of ensuring that older codebases or systems are able to work with new APL dialects, versions, or libraries. Since its early development, APL—and in particular widely used commercial dialects—has had a strong emphasis on backwards compatibility. However, there have also been several significant languages that retain core APL ideas while breaking compatibility, including Iverson's own J. Ideas from these languages are sometimes incorporated back into mainstream, backwards-compatible APLs.

APL dialects that emphasize backward compatibility typically apply greater caution when designing features in order to preserve the possibility for extension in the future, and may even consider forward compatibility—the ability for an older system to work, or fail safely, with newer features—when designing. Features designed with less care in the past may cause language inconsistencies in the future indefinitely. For example, Membership's behavior on high-rank arrays is incompatible with and less useful than other high-rank set functions, but extending it in the new way would break too much existing code for commercial APLs to consider it.


APL dialects that historically have strongly emphasized backwards compatibility include:

In the 1970s and early 1980s it was common to create new APL implementations to run on new hardware. These implementations almost always shared the primitive set of APL.SV or another IBM APL, but often developed new system functions or other peripheral functionality to better match the host system.

Even the languages listed above may make changes to existing behavior. Dyalog APL version 13.0 broke compatibility for the Power function while introducing complex numbers, and was controversial decision for that and other reasons.

Notable APL dialects or offshoots that discard backwards compatibility with APL in significant ways include:

Of these, J has build a large enough user base to develop its own backwards compatibility concerns, even though early J design was fairly loose with respect to backwards compatibility. Beginning with version 8.07 in 2018 it has removed various features that are considered less important.

Newer and less commercial APLs such as APL\iv, April, or ngn/apl tend to be less focused on backwards compatibility than historical ones. These dialects tend to take most design choices from a well-known APL such as Dyalog APL or GNU APL, but make small breaks for experimentation or address particular issues. They typically do not support features that were historically important but are now rarely used, such as shared variables or Branch, and may discard features that are still in use but have an adequate replacement, for example removing tradfns in favor of dfns.

External links

APL development [edit]
Interface SessionTyping glyphs (on Linux) ∙ FontsText editors
Publications IntroductionsLearning resourcesSimple examplesAdvanced examplesMnemonicsStandardsA Dictionary of APLCase studiesDocumentation suitesBooksPapersVideosPeriodicalsTerminology (Chinese, German) ∙ Neural networksError trapping with Dyalog APL (in forms)
Sharing code Backwards compatibilityAPLcartAPLTreeAPL-CationDfns workspaceTatinCider
Implementation Developers (APL2000, Dyalog, GNU APL community, IBM, IPSA, STSC) ∙ ResourcesOpen-sourceMagic functionPerformanceAPL hardware