2,951
edits
APL Wiki:Content guidelines: Difference between revisions
Jump to navigation
Jump to search
APL Wiki:Content guidelines (view source)
Revision as of 13:47, 10 February 2021
, 13:47, 10 February 2021→What is APL?: Define an APL dialect, instead of refusing to define it
(→Verifiability: It's still better to rely on references than special verifiability rules) |
(→What is APL?: Define an APL dialect, instead of refusing to define it) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
== What is APL? == | == What is APL? == | ||
The APL Wiki is focused on APL, which is somewhat problematic because APL has no agreed-upon definition. | The APL Wiki is focused on APL, which is somewhat problematic because APL has no agreed-upon definition. On the APL Wiki we define an [[:Category:APL dialects|APL dialect]], or "an APL", to be a programming language that encodes [[Iverson notation]] in a text-based and machine-executable form, using the syntax and symbols established by the first such language to be publically available, [[APL\360]]. This includes [[A+]], but not similar languages with different symbols like [[ELI]], [[J]], or [[BQN]]: these should be called "languages" rather than "dialects". | ||
* | |||
However, the APL Wiki does not merely document facts about APL dialects, but rather concepts that are important to users of APL. For this purpose it's important to discern not just whether a language is or isn't an APL dialect, but to what extent it can be considered a member of the APL family. Features that make a language APL-like might include: | |||
* Features from the original [[IBM]] implementation of APL, [[APL\360]] | |||
* [[Ken Iverson]]'s ideas of what APL should look like, realised in [[APL\360]], [[SHARP APL]], [[Rationalized APL]], [[A Dictionary of APL]], and [[J]] | * [[Ken Iverson]]'s ideas of what APL should look like, realised in [[APL\360]], [[SHARP APL]], [[Rationalized APL]], [[A Dictionary of APL]], and [[J]] | ||
* | * Typically called "APL" by the APL community | ||
* | * The central concepts of Iverson's APL, like [[array]]s as the fundamental datatype, [[glyph]]s to represent [[primitive function|primitive functions]] and [[primitive operator|operators]], infix notation, and [[Evaluation order|right-to-left]] evaluation | ||
* Developments adopted by substantial portions of the community of APLers, such as the [[nested array model]]. | * Developments adopted by substantial portions of the community of APLers, such as the [[nested array model]]. | ||
Other than the term "APL dialect", the APL Wiki doesn't assign any "APL score" or make any other direct statement of how APL-like a language is. Instead, an editor should consider the task of balancing how central a concept is to APL against its prominence and placement in the APL Wiki. See [[#Due weight]] below. | |||
== Notability == | == Notability == | ||
| Line 51: | Line 54: | ||
In a dialect-specific article, you can assume (because you have told the reader) that the reader knows the page pertains to one APL only. This means it's acceptable to use terms like [[Disclose]] that are ambiguous in general but have only one meaning in the context of that APL, or terms like [[tradfn]] that many parts of the APL community don't use. Despite this, your primary aim should be to make the article useful for a general reader, who might never have heard of this APL. Use terminology which would be most readable for the wider APL community while remaining intelligible from the specific dialect's perspective. If there is no single term that fits, use a dialect-specific one but clarify by mentioning an identical or analogous term in parentheses. | In a dialect-specific article, you can assume (because you have told the reader) that the reader knows the page pertains to one APL only. This means it's acceptable to use terms like [[Disclose]] that are ambiguous in general but have only one meaning in the context of that APL, or terms like [[tradfn]] that many parts of the APL community don't use. Despite this, your primary aim should be to make the article useful for a general reader, who might never have heard of this APL. Use terminology which would be most readable for the wider APL community while remaining intelligible from the specific dialect's perspective. If there is no single term that fits, use a dialect-specific one but clarify by mentioning an identical or analogous term in parentheses. | ||
The guidelines about dialect-specific terminology extend to pages about a group of dialects or languages if these share similar terminology (such as [[K]] derivatives). However, if an article pertains to multiple dialects with very different terminology, choose a single set of terminology in order to make the article consistent rather than switching between them. This may be either the most well-known of the dialects in question, or terminology from a mainstream APL or widely used across APLs. | |||
For articles about a specific dialect, not just pertaining to it (such as [[A+]] or [[Dyalog APL versions]]), the emphasis is in the other direction: '''always give a language's preferred terminology on its own page''' when there is a clear preference. In order to make the page usable for general APL programmers, clarify terminology which is not obvious in parentheses: for example, the page on [[K]] lists the function "flip ([[Transpose]])". | For articles about a specific dialect, not just pertaining to it (such as [[A+]] or [[Dyalog APL versions]]), the emphasis is in the other direction: '''always give a language's preferred terminology on its own page''' when there is a clear preference. In order to make the page usable for general APL programmers, clarify terminology which is not obvious in parentheses: for example, the page on [[K]] lists the function "flip ([[Transpose]])". | ||