Dyalog Forums

ray wrote: On page 7 in the paragraph "Namespaces", is the note:

Note that for Dyalog APL, ⊃ is Mix using ⎕ML←3 for read‐
ability outside the Dyalog community.

(…)
However should this note itself, actually appear before the first use of "⊃" in the examples earlier on page 7?

Yes, thank you. I will correct that.

ray wrote:Will the proposed extensions work in a workspace (as against within a function or script).

I am thinking around the problem relating to "Extended Multiline Input".

And will one be able to edit the array directly in the session?

Yes, it will be an integrated part of the language. We're even planning to use the notation in the editor, so you can edit more arrays than currently possible (just text arrays).

The document makes a single reference to the functions "Serialise" and "Deserialise" in the model at ⎕SE.Dyalog.Array.

I pointed out here https://forums.dyalog.com/viewtopic.php ... 1872#p7460 that that functionality would need to be provided such that existing arrays could be encoded into Array Notation (AN) for embedding or transmitting - as ⎕JSON exports JSON - and sources of AN such as file content or received transmissions could be evaluated as per ⎕JSON import. I suggested that enhancements involving new ways to call ⍕ and ⍎ would do the job; perhaps with a new type of left argument or variant.

The document makes no mention of this requirement. When AN becomes an integral part of APL it would seem unfortunate were we still to have to load a namespace in order to use it fully. Even assuming they continue to exist those two functions will presumably be rewritten merely to call the primitive code.

An example of its use and a way to overcome the limits of the proposed enhancement to ⎕ED is

.
 edit←{
     z←⍕⍠'Array Notation'⊢ ⍵
     x←⎕ED'z'
     ⍎⍠'Array Notation'⊢ z
 }

where the AN encoding is presented for editing and the evaluated array is returned.
It can be tried now within the limitations of the model

,
 edit←{
     AN←⎕SE.Dyalog.Array
     z←AN.Serialise ⍵
     x←⎕ED'z'
     AN.Deserialise z
 }

My apologies to Adam if I misconstrued his

so you can edit more arrays than currently possible (just text arrays).

On rereading it I see that the parenthesis applies to the current limitation, not the enhancement.

Phil Last wrote:The document makes no mention of this requirement (to provide functionality to encode and decode existing arrays)

The document intentionally makes no reference to how individual APL implementations would make use of the notation. For example, some implementations might decide to only view it as a modern "transfer form".

In Dyalog APL, the intention is to make Array Notation part of the core language, so you will be able to write AN directly in APL functions or operators. This implies that we will come up with ways for ⍎ and ⍕ (or perhaps system functions) to do useful things with AN. We will probably provide a "safe" variant of ⍎ while we are at it, which only allows you to define constants without "running" anything.

Over time, the availability of a notation for literal namespaces is likely to lead to many enhancements to the way we provide arguments or variant specifications to system functions - perhaps eventually user-defined functions as well.