Backwards compatibility: Difference between revisions

From APL Wiki
Jump to navigation Jump to search
m (→‎Dialects: Fix Dyalog version links)
m (Text replacement - "<source" to "<syntaxhighlight")
 
(8 intermediate revisions by 2 users not shown)
Line 2: Line 2:


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 [[wikipedia:forward compatibility|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 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 [[wikipedia:forward compatibility|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.
== Scope ==
Different features in an APL implementation are usually subject to different levels of backwards compatibility constraint. The results of primitives, and the meaning of syntax, are always considered the most important to maintain, while [[system function]]s are often handled more loosely and [[I-beam]]s or [[user command]]s may have very low backwards compatibility requirements.
The specific [[error message]]s produced by any given error is considered less important keep constant. The standards indeed leave it up to the implementations too decide the order in which various aspects of code validity is checked. For example <syntaxhighlight lang=apl inline>'ABC'×1 2 3 4</syntaxhighlight> could be a [[LENGTH ERROR]] (3 vs. 4 elements) or a [[DOMAIN ERROR]] (attempting to multiply characters). Implementations are known to change the precedence of such errors.
Errors can disappear altogether when the domains of [[primitive]]s are extended, or additional syntax is added. For example, it is common practice to insert a deliberate error into a function, in order to force execution to halt, and the tracing interface to appear. The traditional way to do so was to insert a line with one a function on it. The [[FinnAPL idiom library]] includes
:{|class=wikitable style="background-color: #EBEBEB"
|rowspan=2| 738. || Syntax error to stop execution ||style="text-align: right;"|<syntaxhighlight lang=apl inline></syntaxhighlight>
|-
|colspan=2 style="background-color: #F5F5F5"|<syntaxhighlight lang=apl inline>*</syntaxhighlight>
|}
but this will simply print <syntaxhighlight lang=apl inline>*</syntaxhighlight> in dialects that [[Tacit_programming#Primitives|allow primitive functions to be named]]. Another common phrase was <syntaxhighlight lang=apl inline>***</syntaxhighlight> as this is easy to search for while being exceedingly unlikely to appear in code. However, with the adoption of [[train]]s, this too became valid, and is likely to print verbatim rather than stop execution. [[APLcart]] includes <syntaxhighlight lang=apl inline>...</syntaxhighlight> for the same purpose, relying on the continued prohibition against immediately adjacent [[dyadic operator]]s other than for [[outer product]] (<syntaxhighlight lang=apl inline>∘.g</syntaxhighlight>).


== Dialects ==
== Dialects ==
Line 11: Line 25:
* [[Dyalog APL]], particularly in the 1990s and later
* [[Dyalog APL]], particularly in the 1990s and later
* [[GNU APL]] relative to [[ISO/IEC_13751:2001]]
* [[GNU APL]] relative to [[ISO/IEC_13751:2001]]
* [[Extended Dyalog APL]] relative to Dyalog, although this compatibility was broken by Dyalog [[Dyalog APL 18.0|version 18.0]].
* [[Extended Dyalog APL]] relative to Dyalog, although this compatibility was broken by Dyalog [[Dyalog APL 18.0|version 18.0]]'s addition of [[Unique Mask]].


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 function]]s or other peripheral functionality to better match the host system.
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 function]]s or other peripheral functionality to better match the host system.


Even the languages listed above may make changes to existing behavior. [[Dyalog APL 13.0]] broke compatibility for the [[Power]] function while introducing [[complex number]]s, and was controversial decision for that and other reasons.
Even the languages listed above may make changes to existing behavior. [[APL2]] broke from [[APL\360]] by promoting [[bracket indexing]] to higher [[precedence]] than [[stranding]], a decision that wasn't taken up by its contemporary [[Dyalog APL]], but was shared by some later dialects including [[APLX]] and [[GNU APL]]. More recently, [[Dyalog APL 13.0]] broke compatibility for the [[Power]] function while introducing [[complex number]]s, which were controversial feature for that and other reasons. Some dialects include a [[compatibility setting]] as a [[system variable]].


Notable APL dialects or offshoots that discard backwards compatibility with APL in significant ways include:
Notable APL dialects or offshoots that discard backwards compatibility with APL in significant ways include:
Line 26: Line 40:
* [[BQN]] for numerous reasons including [[leading axis theory]], redesigned [[glyph]]s, and removing implicit [[stranding]]
* [[BQN]] for numerous reasons including [[leading axis theory]], redesigned [[glyph]]s, and removing implicit [[stranding]]


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.
Of these, [[J]] has built 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 [[tradfn]]s in favor of [[dfn]]s.
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 [[tradfn]]s in favor of [[dfn]]s.
Line 33: Line 47:


* [[wikipedia:Backward compatibility|Backward compatibility]]
* [[wikipedia:Backward compatibility|Backward compatibility]]
* [https://github.com/abrudz/KINGDOM KINGDOM] (an example of the minimal changes necessary for an [[APL\360]] game to run on modern [[Dyalog APL]] and being served as a web app)
{{Template:APL development}}[[Category:APL history]][[Category:Culture]]
{{Template:APL development}}[[Category:APL history]][[Category:Culture]]

Latest revision as of 21:44, 10 September 2022

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.

Scope

Different features in an APL implementation are usually subject to different levels of backwards compatibility constraint. The results of primitives, and the meaning of syntax, are always considered the most important to maintain, while system functions are often handled more loosely and I-beams or user commands may have very low backwards compatibility requirements.

The specific error messages produced by any given error is considered less important keep constant. The standards indeed leave it up to the implementations too decide the order in which various aspects of code validity is checked. For example 'ABC'×1 2 3 4 could be a LENGTH ERROR (3 vs. 4 elements) or a DOMAIN ERROR (attempting to multiply characters). Implementations are known to change the precedence of such errors.

Errors can disappear altogether when the domains of primitives are extended, or additional syntax is added. For example, it is common practice to insert a deliberate error into a function, in order to force execution to halt, and the tracing interface to appear. The traditional way to do so was to insert a line with one a function on it. The FinnAPL idiom library includes

738. Syntax error to stop execution
*

but this will simply print * in dialects that allow primitive functions to be named. Another common phrase was *** as this is easy to search for while being exceedingly unlikely to appear in code. However, with the adoption of trains, this too became valid, and is likely to print verbatim rather than stop execution. APLcart includes ... for the same purpose, relying on the continued prohibition against immediately adjacent dyadic operators other than for outer product (∘.g).

Dialects

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. APL2 broke from APL\360 by promoting bracket indexing to higher precedence than stranding, a decision that wasn't taken up by its contemporary Dyalog APL, but was shared by some later dialects including APLX and GNU APL. More recently, Dyalog APL 13.0 broke compatibility for the Power function while introducing complex numbers, which were controversial feature for that and other reasons. Some dialects include a compatibility setting as a system variable.

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

Of these, J has built 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