bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-apl] )COPY with APL scripts


From: Juergen Sauermann
Subject: [Bug-apl] )COPY with APL scripts
Date: Wed, 8 Feb 2017 21:45:25 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]