4,493
edits
Backwards compatibility: Difference between revisions
Jump to navigation
Jump to search
m
Backwards compatibility (view source)
Revision as of 21:44, 10 September 2022
, 21:44, 10 September 2022Text replacement - "<source" to "<syntaxhighlight"
(Add scope section and move error message discussion there) |
m (Text replacement - "<source" to "<syntaxhighlight") |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
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. | 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 < | 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 | 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" | :{|class=wikitable style="background-color: #EBEBEB" | ||
|rowspan=2| 738. || Syntax error to stop execution ||style="text-align: right;"|< | |rowspan=2| 738. || Syntax error to stop execution ||style="text-align: right;"|<syntaxhighlight lang=apl inline></syntaxhighlight> | ||
|- | |- | ||
|colspan=2 style="background-color: #F5F5F5"|< | |colspan=2 style="background-color: #F5F5F5"|<syntaxhighlight lang=apl inline>*</syntaxhighlight> | ||
|} | |} | ||
but this will simply print < | 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 29: | Line 29: | ||
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. [[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. | 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 47: | 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 modern [[Dyalog APL]] and | * [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]] | ||