4,493
edits
Backwards compatibility: Difference between revisions
Jump to navigation
Jump to search
Backwards compatibility (view source)
Revision as of 08:09, 25 October 2020
, 08:09, 25 October 2020→Dialects
m (→Dialects: Fix Dyalog version links) |
|||
| Line 11: | Line 11: | ||
* [[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. | ||
| Line 19: | Line 19: | ||
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: | ||
* [[Ken Iverson|Iverson]]'s papers [[Rationalized APL]] and [[A Dictionary of APL]] | * [[Ken Iverson|Iverson]]'s papers [[Rationalized APL]] and [[A Dictionary of APL]] | ||
* [[APL2]] (and thus [[APLX]] and [[GNU APL]]) promoted [[bracket indexing]] to higher precedence than [[stranding]] while e.g. [[Dyalog APL]] retained [[APL\360]]'s precendence | |||
* [[A+]], primarily because [[leading axis theory]] allows primitives to be removed or simplified | * [[A+]], primarily because [[leading axis theory]] allows primitives to be removed or simplified | ||
* [[J]] to use only the [[wikipedia:ASCII|ASCII]] character set, [[leading axis theory]], and other primitive changes | * [[J]] to use only the [[wikipedia:ASCII|ASCII]] character set, [[leading axis theory]], and other primitive changes | ||
| Line 26: | Line 27: | ||
* [[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 | 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. | ||
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 <source lang=apl inline>'ABC'×1 2 3 4</source> 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;"|<source lang=apl inline></source> | |||
|- | |||
|colspan=2 style="background-color: #F5F5F5"|<source lang=apl inline>*</source> | |||
|} | |||
but this will simply print <source lang=apl inline>*</source> in dialects that [[Tacit_programming#Primitives|allow primitive functions to be named]]. Another common phrase was <source lang=apl inline>***</source> 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 <source lang=apl inline>...</source> for the same purpose, relying on the continued prohibition against immediately adjacent [[dyadic operator]]s other than for [[outer product]] (<source lang=apl inline>∘.g</source>). | |||
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. | ||