Talk:Array notation design considerations

Although I agreed with Marshall that the current implementation(s) should be separated from the history the division should be entirely transposed. The concepts may have been driven largely by Phil Last and secondarily by Adám Brudzewsky both of whom are mostly associated with Dyalog but the history proper ranges well beyond the confines of a few Dyalog conferences and the offices at Bramley.

The current page should be entitled "Array Notation" and what is now "Array notation in Dyalog APL" shoud be "Array Notation - implementations" with Dyalog being one section within it. --Phil Last (talk) 08:50, 19 August 2022 (UTC)

I'll add what I know about the history to the main page. I wasn't aware of the APL# design, so thanks for pointing that out. Most of what you've written doesn't seem appropriate for a wiki, and I'd recommend instead publishing it somewhere else under your name and citing it here. If the conversations with John Scholes are private emails, they're not verifiable by a reader unless sourced this way. And as a reader I'm not interested in things like internal issue numbers and half-formed unpublished ideas like :Array. There's a reason Wikipedia says things like "If you have a personal connection to a topic or person, you are advised to refrain from editing those articles directly". We're not so strict about this, but my judgment here (as someone who also has a personal connection!) is that it's interfering with the information density that most readers would want. --Marshall (talk) 12:50, 19 August 2022 (UTC)

Having read the relevant parts of the APL# language description I disagree with the description you've given. A namespace is a list of expressions, not name-value pairs: for example [[ a←b←⍳10 ⋄ {a[⍵]←0}¨2 4 6 ]] would be allowed. Having not worked with :namespace I may be missing some details, but it seems [[ and ]] function identically to :Namespace and :EndNamespace and those aren't considered array notation. It's still relevant to the history but the framing as a kind of array notation seems misleading to me. Similarly, I took out the section on NARS: there's no discussion of the display as a way to write arrays in the manual, and multi-line printout with parentheses appears to be purely for display. So Adám's claim that "the need for a way to represent complex structures was already recognised" is speculative unless there's a source I haven't seen. --Marshall (talk) 14:41, 19 August 2022 (UTC)

---

I also saw no relevance in the NARS formatting but left it in because someone else obviously saw it differently. I've tried to recast my contribs more objectively but feel that your criticism would apply equally to most of what was here already.

With regard to APL#:

• in APL there's no real distinction between value and expression.
• if [[name ← (value of) expression]] isn't array notation then I don't see how "( name : (value of) expression )" can be.
• My 2015 talk makes clear that a dictionary (namespace - whatever) is a particular form of array and deserves to be a part of the notation.

If the history of a notation is of relevance and interest then it's a history of ideas that grow and change. Insights that go toward formulating those ideas are therefore relevant. --Phil Last (talk) 22:55, 19 August 2022 (UTC)

Aside, I've noted my objections to publishing as a pdf here on the relevant page. Yes, my criticism applies to other parts of the page. I don't think it achieves APL Wiki's goal of an encyclopedic presentation, that is, informative and digestible for the average APL programmer. I moved it because deleting is a drastic measure.

Relevance is relative; see undue weight. Compare to control structures which has much less detail for a much more written-about topic. The sources are there as citations if the reader wants to dig into them.

The description of APL#'s notation as consisting of "name-value pairs" with "major and minor separators being line-end and assignment arrow" is wrong: that's not the syntax it uses. --Marshall (talk) 23:06, 19 August 2022 (UTC)