4,494
edits
Template talk:APL built-ins: Difference between revisions
Jump to navigation
Jump to search
m
Template talk:APL built-ins (view source)
Revision as of 10:29, 11 September 2022
, 10:29, 11 September 2022Text replacement - "</source>" to "</syntaxhighlight>"
m (Text replacement - "</source>" to "</syntaxhighlight>") |
|||
| Line 1: | Line 1: | ||
== Grouping primitives == | == Grouping primitives == | ||
Putting my thoughts here in the hopes that we'll eventually come to a better solution. There's no urgency to this, however, and I don't really have any idea what to do yet. Our current system is based on [[Dyalog]]'s, which I find unintelligible: why is [[Drop]] selection but [[Rotate]] structural? Would [[Sort by]] (like <source lang=apl inline>{⍺[⍋⍵]}</ | Putting my thoughts here in the hopes that we'll eventually come to a better solution. There's no urgency to this, however, and I don't really have any idea what to do yet. Our current system is based on [[Dyalog]]'s, which I find unintelligible: why is [[Drop]] selection but [[Rotate]] structural? Would [[Sort by]] (like <source lang=apl inline>{⍺[⍋⍵]}</syntaxhighlight>) be selection or selector? Since it doesn't seem to me that Dyalog's system reflects usage either across APLs or in the community, I think it's better to make one of our own based on goals that make sense for an encyclopedic wiki. | ||
Relatively recently, I added the category system, so that primitives can be placed in subcategories of [[:Category:APL primitives]] (and other built-ins in [[:Category:APL built-ins]]). Categories allow us to have overlapping groupings for primitives, so that for example [[Membership]] can be both a search function and a set function. However, they should be limited to groupings that are widely used and whose members are mostly agreed upon. No one's interested in a "Computational primitive functions according to Dyalog APL" category, and no one would ever agree on what to put in a "Computational primitive functions" category. But having a category system means we don't have to try to convey these kinds of essential categories in the navbox, unless they help with navigating the primitives. | Relatively recently, I added the category system, so that primitives can be placed in subcategories of [[:Category:APL primitives]] (and other built-ins in [[:Category:APL built-ins]]). Categories allow us to have overlapping groupings for primitives, so that for example [[Membership]] can be both a search function and a set function. However, they should be limited to groupings that are widely used and whose members are mostly agreed upon. No one's interested in a "Computational primitive functions according to Dyalog APL" category, and no one would ever agree on what to put in a "Computational primitive functions" category. But having a category system means we don't have to try to convey these kinds of essential categories in the navbox, unless they help with navigating the primitives. | ||