2,951
edits
Backwards compatibility: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
m (→Dialects) |
mNo edit summary |
||
| 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 == | ||