APL Wiki
Left, Right, or the Same?
Something that was talked about at the November 2009 meeting of London-based APL users was that it might be useful for the APL Wiki to contain summaries of online discussions which had happened at places like comp.lang.apl and the dyalogusers mailing list. This is a first attempt at such a summarisation, brought about by suggestions that Dyalog might introduce some new primitive functions. If you don't like it, feel free to change it - if you really don't like it, feel free to delete it.
Left, Right Dyadic Forms
Both Sharp APL and J have for some time included primitive functions which returned either their left or right arguments (unchanged). There was little contention about these dyadics aside from naming, some preferring to follow the Sharp APL "lev" and "dex", others preferring J's "left" and "right".
The symbols proposed are ⊣ and ⊢ respectively.
Notice that these functions are quite different from APL2's "left" and "right".
Discussion
Could someone explain how lev and dex differ from the APL2 implementation? We just added APL2-compatible support for ⊣ and ⊢ in APLX Version 5. Sounds wrong to have an incompatible implementation in Dyalog if it can be avoided (-- SimonMarsden 2009-12-31 10:14:51)
As I hinted, APL2's ⎕L and ⎕R are something completely different (hiding under a similar name) - I don't think APL2 recognises the ⊣ and ⊢ characters (I just got a SYNTAX ERROR when I tried 2 ⊣ 3 (APL2 V2 SL 14 on Windows 7) (-- DickBowman 2009-12-31 10:35:00).
Thanks, Dick. You're right. I mis-remembered. I believe that ⊣ and ⊢ are part of the extended ISO APL standard (ISO/IEC13751) but it appears that APL2 doesn't implement them. (-- SimonMarsden 2009-12-31 11:29:45)
⊣ and ⊢ have more suggestive uses, and several proposals predate this one. ⊢ is graphically related to floor ⌊ and ceiling ⌈; seen within that set it ought to "Round to nearest". Considering the system-dependent pitfalls of rounding correctly on any machine (No, ⌊X+0.5 is not always the right answer! Not even when you set ⎕CT to 0...) , a built-in notation for this tool of thought would be so nice; the dyadic A⊢B then rounds B to the nearest A. Both forms act as pervasive numeric functions. I found this so persuasive that I put it into APLB in 1985 and wrote a short QuoteQuad article arguing for it. But, my logician friends also read A B⊢C as "Statements A and B prove the conclusion C"; consensus is never easy. (-- GregJaxon 2011-01-07 13:41:00).
Monadic Form
Agreement on the monadic(s) was less uniform, partly because Sharp APL offered a different model from J.
Some participants preferred the Sharp model, where monadic "lev" offered a black hole into which unwanted results could be thrown.
Others preferred the J model, where monadic ] and monadic [ are both called "same" and do nothing apart from return their argument as the result.
Some participants found it hard to see much utility for the monadic form.
A Related Issue
While most versions of APL react to monadic + and a non-numeric argument with DOMAIN ERROR (consistent with dyadic + and non-numeric arguments), Dyalog has long allowed this and returns the argument unchanged - it is equivalent to "same" in this case. Monadic + on a numeric argument is also an identity, for real numbers.
What makes this matter is that Dyalog might at some point introduce complex numbers, meaning that monadic + would no longer be an identity. Going forward (as we dynamic business leaders say) this ought not be a problem, because monadic "same" offers identity for all arguments.
But, some code exploits Dyalog's specific domain extension and may begin to fail if and when complex numbers are introduced. At this point there has been no resolution of this issue - opinions are divided about whether backward compatibility to what might be considered a design error should be adopted.