trusted
183
edits
APL Wiki:Content guidelines: Difference between revisions
Jump to navigation
Jump to search
m
Fix a red link
(Dialect-specific pages) |
m (Fix a red link) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 9: | Line 9: | ||
* [[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]] | ||
* A language which is typically called "APL" by the APL community | * A language which is typically called "APL" by the APL community | ||
* A language that uses the central concepts of Iverson's APL, like [[array]]s as the fundamental datatype, [[glyph]]s to represent [[primitive]] | * A language that uses 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]]. | ||
The APL Wiki takes no position on what can be called "APL", and this question is not important to its content (when in doubt, a controversial APL such as [[J]] may be called a "language" rather than an "APL" or "dialect"). 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. | The APL Wiki takes no position on what can be called "APL", and this question is not important to its content (when in doubt, a controversial APL such as [[J]] may be called a "language" rather than an "APL" or "dialect"). 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. | ||
| Line 52: | Line 52: | ||
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. | ||
For articles about a specific dialect (such as [[A+]]), 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]])". | ||
Use the principle of [[#Due weight|due weight]] when deciding whether and how to link to a dialect-specific article elsewhere on the APL Wiki. If a concept is closely related to a better known one, it probably deserves a link, but the link should be in a less prominent position if the dialect with that concept is obscure. Less closely related concepts or non-obvious connections (for example, [[Raze]] is a left inverse of [[Partition]] and [[Partitioned Enclose]] on vectors) may or may not merit a link. | Use the principle of [[#Due weight|due weight]] when deciding whether and how to link to a dialect-specific article elsewhere on the APL Wiki. If a concept is closely related to a better known one, it probably deserves a link, but the link should be in a less prominent position if the dialect with that concept is obscure. Less closely related concepts or non-obvious connections (for example, [[Raze]] is a left inverse of [[Partition]] and [[Partitioned Enclose]] on vectors) may or may not merit a link. | ||
| Line 58: | Line 58: | ||
== Verifiability == | == Verifiability == | ||
We make use of Wikipedia's definition [[wikipedia:wikipedia:Verifiability|verifiability]], but expand the definition somewhat to allow some kinds of material that would otherwise remain undocumented. | We make use of Wikipedia's definition [[wikipedia:wikipedia:Verifiability|verifiability]], but expand the definition somewhat to allow some kinds of material that would otherwise remain undocumented. Even if these rules were used it can be helpful to the reader to have a secondary source that more directly states the information, so if you are aware of a traditional encyclopedic reference (other than the published documentation, which is too obvious to justify the clutter), consider adding a citation. | ||
The results of '''evaluating an expression''' in any array language, even one which is not readily available to the public, are automatically considered verifiable. Please actually perform this evaluation if you are relying on this rule! Results are also considered verifiable if they may be clearly derived from the language's published documentation. | The results of '''evaluating an expression''' in any array language, even one which is not readily available to the public, are automatically considered verifiable. Please actually perform this evaluation if you are relying on this rule! Results are also considered verifiable if they may be clearly derived from the language's published documentation. | ||
'''Mathematical statements about APL with proof''' are considered to be verifiable. If you derive a new relation between APL primitives, and can prove it to a capable APLer, then feel free to put it on the wiki. Make sure you are clear about exactly which functions you are using, including distinguising between variations on APL primitives and noting any modifications or restrictions need to be made for the proven statement to hold. | '''Mathematical statements about APL with proof''' are considered to be verifiable. If you derive a new relation between APL primitives, and can prove it to a capable APLer, then feel free to put it on the wiki. Make sure you are clear about exactly which functions you are using, including distinguising between variations on APL primitives and noting any modifications or restrictions need to be made for the proven statement to hold. | ||