Operand: Difference between revisions
m (4 revisions imported: Migrate from miraheze) |
m (Operators category) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
In [[APL syntax]], an '''operand''' is one of the values used by an [[operator]] to form a [[derived function]]. Operands are distinguished from [[argument]]s, the values accepted by the derived function or other [[function]]s. Operators are divided into [[monadic operator|monadic]] and [[dyadic operator]]s depending on how many | In [[APL syntax]], an '''operand''' is one of the values used by an [[operator]] to form a [[derived function]]. Operands are distinguished from [[argument]]s, the values accepted by the derived function or other [[function]]s. Operators are divided into [[monadic operator|monadic]] and [[dyadic operator]]s depending on how many operands they take; like [[niladic]] versus non-niladic functions the [[operator valence|valence]] is inherent in the operator rather than determined by context. Operator valence is thus substantially different from [[function valence]] as [[monadic]] and [[dyadic]] functions are distinguished by context. | ||
In [[APL\360]] and many later APLs, only functions were allowed as operands. Modern APLs tend to allow array operands for operators such as [[Power operator|Power]] and [[Rank operator|Rank]]. While there is no syntactic consideration that prevents this, it can cause frustration while programming due to [[strand notation]]. If operators only take function operands and functions only take array arguments, then it is impossible for two arrays to appear next to each other in an APL sentence and thus this syntax can be repurposed for stranding. With array operands this is no longer the case, and stranding conflicts with operator application. Some APLs resolve this conflict by stranding before operator application while others apply operators before stranding. | In [[APL\360]] and many later APLs, only functions were allowed as operands. Modern APLs tend to allow array operands for operators such as [[Power operator|Power]] and [[Rank operator|Rank]]. While there is no syntactic consideration that prevents this, it can cause frustration while programming due to [[strand notation]]. If operators only take function operands and functions only take array arguments, then it is impossible for two arrays to appear next to each other in an APL sentence and thus this syntax can be repurposed for stranding. With array operands this is no longer the case, and stranding conflicts with operator application. Some APLs resolve this conflict by stranding before operator application while others apply operators before stranding. | ||
{{APL syntax}} | {{APL syntax}}[[Category:Operators]] | ||
Latest revision as of 15:15, 30 April 2020
In APL syntax, an operand is one of the values used by an operator to form a derived function. Operands are distinguished from arguments, the values accepted by the derived function or other functions. Operators are divided into monadic and dyadic operators depending on how many operands they take; like niladic versus non-niladic functions the valence is inherent in the operator rather than determined by context. Operator valence is thus substantially different from function valence as monadic and dyadic functions are distinguished by context.
In APL\360 and many later APLs, only functions were allowed as operands. Modern APLs tend to allow array operands for operators such as Power and Rank. While there is no syntactic consideration that prevents this, it can cause frustration while programming due to strand notation. If operators only take function operands and functions only take array arguments, then it is impossible for two arrays to appear next to each other in an APL sentence and thus this syntax can be repurposed for stranding. With array operands this is no longer the case, and stranding conflicts with operator application. Some APLs resolve this conflict by stranding before operator application while others apply operators before stranding.