2,954
edits
Backwards compatibility: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
m (→Dialects) |
mNo edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
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 [[Ken Iverson|Iverson]]'s own [[J]]. Ideas from these languages are sometimes incorporated back into mainstream, backwards-compatible APLs. | 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 [[Ken Iverson|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 [[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 | 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 [[major cell search]], but extending it in the new way would break too much existing code for commercial APLs to consider it. | ||
== Scope == | == Scope == | ||
| Line 41: | Line 41: | ||
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. [[BQN]] now strongly emphasizes backwards compatibility. | 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. [[BQN]] now strongly emphasizes backwards compatibility. | ||
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 | 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 variable]]s 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. | ||
== See also == | == See also == | ||