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 <juergen.sauerm...@t-online.de> 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 > > -- Br, /Alexey
