Re: [Bug-apl] )COPY with APL scripts

[Juergen Sauermann]

Hi Alexey,

the output of eg. ⍎"COPY XXX.apl" is a string which can be assigned or suppressed like this:

      ⊣⍎"COPY XXX.apl"

A ⎕COPY would be behave exactly as ⍎")COPY ..." does, so just renaming ⍎")COPY ..." to ⎕COPY would not
help. The problem is not in )COPY itself but in the fact that a script (as opposed to a workspace) is being )COPYd.

With my post I just wanted to make GNU APL users aware of how )COPY of APL scripts works and that there
could be non-obvious problems when ⍎")COPY  ..." is called from a defined function. In most cases even that
works fine, but sometimes it does not, and the reasons are those that I explained below.

Most people use )COPY at the beginning of their script and that causes no problems.

/// Jürgen

On 02/08/2017 11:08 PM, Alexey Veretennikov wrote:

Hi,

If you can introduce the option to suppress output on )copy like "Dumped
..." it will reduce neccesity to use ⍎ with )copy.

Personally I see )copy as similar to Java's import or Python's import,
so it allows me to use functions and variables declared in another
script.

If it is too much for this command, some system function could be
introduced, like ⎕copy or ⎕import for the same purposes without the
drawbacks of )copy. 

Juergen Sauermann <address@hidden> writes:

Hi,

In GNU APL, copying an APL workspace (i.e. an .xml file) with the )COPY command is an atomic
operation.

However, )COPY of a script (i.e. an .apl file) is not atomic. The )COPY command opens the file and
displays,
as a result. when the file was )DUMPed. The )COPY command has finished at this point, but the loading of
the
file has not. The content of the file is read at a later point in time, namely when the interpreter enters
immediate execution. This is because the file contains a mix of APL commands, APL expressions, and
function definitions in the same format as the user would enter them interactively. That is, I believe, what
most users would expect from
a script - that it simulates the input of the user. The potential content of the .apl file, for example function
definitions
with the ∇-editor, or the )SIC command, depend heavily on the fact that the interpreter is in a well known
state like immediate execution mode.

If the interpreter is already in immediate execution then )COPY of a script will execute the lines off the
script and
return to immediate execution (at least when the script was created with the )DUMP command. A
hand-crafted
script may remain in APL evaluation mode if it contains an endless loop. That case is not considered here).

Now, if we do

)COPY script.apl
)FNS

in immediate execution mode, then )COPY will finish quickly and return to immediate execution mode and
)FNS will
be executed after )COPY was completely executed. So we see the functions copied from script.apl.

As of lately a new feature in GNU APL was that some (actually most) of the APL commands can be
executed with ⍎.
It is not obvious that the following innocent looking function foo, which uses this feature

∇foo
⍎")COPY script.apl"
⍎")FNS"
∇

is not doing the same as the commands that we entered in immediate execution mode before. The reason
is that,
after ⍎")COPY script.apl" the interpreter has not yet returned to immediate execution mode. At this point
int time,
script.apl was opened, but the interpreter has not read any lines from it because reading of the lines take
only
place in immediate execution mode. As a consequence the next command, ⍎")FNS" will NOT show any
functions
defined in script.apl.

Because this behaviour is difficult to detect and likely to cause confusion, I have changed GNU APL in SVN
882
so that the execution of certain commands after the ⍎")COPY script.apl" but before the )COPY has
finished will raise an error so that the user is warned:

∇foo
[1] ⍎')COPY 5 HTML'
[2] ⍎')COPY 5 FILE_IO'
[3] ⍎')FNS'
[4] ∇

foo
DUMPED 2017-02-06 13:19:58 (GMT+1) 
DUMPED 2017-02-06 13:19:58 (GMT+1) 
*** )COPY Pending
foo[3] ⍎')FNS'
^

The commands (after )COPY) that may raise this error are those for which )COPY may have made a
difference,
i.e. )FNS, )OPS, )VARS, )NMS, but also another )COPY or )PCOPY. The commands that cannot be ⍎'ed in
the
first place are thise that modify the )SI stack, in particular )LOAD, )SIC, and therefore also )CLEAR.

BTW: if you see the )COPY pending error, then the error has brought you back to immediate execution
mode.
And consequently the pending )COPY has been executed already. Therefore →⍬ will continue foo (in the
abovce example) at the point where the error had occurred.

/// Jürgen Sauermann