Array Notation Discussion

General APL language issues
User avatar
Adam|Dyalog
Posts: 143
Joined: Thu Jun 25, 2015 1:13 pm

Re: Array Notation Discussion

Post by Adam|Dyalog »

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.
User avatar
Adam|Dyalog
Posts: 143
Joined: Thu Jun 25, 2015 1:13 pm

Re: Array Notation Discussion

Post by Adam|Dyalog »

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).
User avatar
Phil Last
Posts: 628
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex

Re: Array Notation Discussion

Post by Phil Last »

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
 }
User avatar
Phil Last
Posts: 628
Joined: Thu Jun 18, 2009 6:29 pm
Location: Wessex

Re: Array Notation Discussion

Post by Phil Last »

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.
User avatar
Morten|Dyalog
Posts: 460
Joined: Tue Sep 09, 2008 3:52 pm

Re: Array Notation Discussion

Post by Morten|Dyalog »

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.
Post Reply