Re: ending/stopping a script

[enztec]

Hi

every scripting language has a simple way to end script execution using code 
that 'reflects' the nature of the language's syntax - thus
bash - exit
python - exit
php - exit
perl - exit

i thought as tempting as it is to use →/→0 to end a script would be nice - 
their use probably should be left specific for use in fns (real effect depends 
on )SI/)SIC)

and in keeping with the single character nature of apl - I suggest using '.' as 
first character on script line as way to end script\

using ⎕stop in an apl script doesn't keep to the character of apl coding

On Mon, 14 Jun 2021 12:59:33 +0200
Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:

> Hi,
>
> actually N ⎕STOP B sets onr otr more breakpoints on line(s) N in the defined
> function named B and it returns the current stop vector of the
> functions. In my example,
> the breakpoint is only reached if the dummy function STOP (you
> can choose a different name if you prefer) is being called (in your script).
>
> I noticed that ⎕STOP (which is an ISO standard construct) comes from
> the time before APL scripting was introduced in GNU APL and for that
> reason only works as expected in )SAVEd workspaces, but not so well
> in )DUMPed ones. This is because after hitting the breakpoint the
> interpreter returns to immediate execution mode.
>
> However, in a )SAVEd workspace this means that the interpreter
> reads the next input line comes from the user while in a )DUMPed
> workspace the next input line comes from either the current script,
> or from the next script, or from the user and therefore execution
> will only stop in the last case but proceed in the first two cases,
>
> This can be addressed in 3 ways:
>
> Option A: fix ⎕STOP so that the current script will be stopped and input
> is obtained (interactively) from the user (until the user issues ]NEXTFILE).
>
> Option B: Add a new command, say ]PUSHFILE, which causes the interpreter
> to read its input (interactively) from the user (until the user issues
> ]NEXTFILE).
>
> Option C: leave things as they are.
>
> Before implementing one of the options above I would like to receive some
> feedback from the  GNU APL users regarding the way forward.
>
> Best Regards,
> Jürgen
>
>
> On 6/13/21 7:33 PM, enztec@gmx.com wrote:
> > Hi
> >
> >
> > not sure exactly what to do here with the ⎕STOP code
> >
> >   > cat script3
> >
> > #! script3
> >
> > '1 aaaaaa'
> >
> > ∇STOP
> >   'STOP CALLED'
> > ∇
> >
> > 1 ⎕STOP 'STOP' ⍝ no output
> >
> > '2 aaaaaa'
> >
> > STOP  ⍝ outputs  STOP[1] but execution continues
> >
> > '3 aaaaaa'
> >
> > 1 ⎕STOP STOP  ⍝ outputs STOP[1] but execution continues
> >
> > '4 aaaaaa'
> >
> > ⍝ stops execution and ws stays open    outputs      
> > IO_Files::open_next_file(): no more files
> > ]NEXTFILE
> >
> > '5 aaaaaa'
> >
> > ⍝ stops exeuction and ws stays open    outputs      
> > IO_Files::open_next_file(): no more files
> > ]nextfile
> >
> > '6 aaaaaa'
> >
> >
> >
> >> /usr/local/bin/apl        loads clear ws
> >        )copy script3
> > DUMPED 2021-06-13  11:26:23 (GMT-6)
> > 1 aaaaaa
> > 2 aaaaaa
> > STOP[1]
> > 3 aaaaaa
> > STOP[1]
> > 4 aaaaaa
> > IO_Files::open_next_file(): no more files
> >
> >
> >
> >
> > On Sat, 12 Jun 2021 11:36:02 +0200
> > Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:
> >
> >> Hi,
> >>
> >> ]NEXTFILE would be my first choice also.
> >>
> >> Alternatively you could think of defining a dummy function like:
> >>
> >> ∇STOP
> >>   'STOP CALLED'
> >> ∇
> >>
> >> and set ⎕STOP to its first line:
> >>
> >> 1 ⎕STOP 'STOP'
> >>
> >> or so,
> >>
> >> The difference is that ]NEXTFILE closes the script file, while
> >> ⎕STOP only stops execution (so you can continue execution
> >> in the same script after making some changes).
> >>
> >> Best Regards,
> >> Jürgen
> >>
> >>
> >>
> >> On 6/12/21 5:46 AM, Kacper Gutowski wrote:
> >> On Fri, Jun 11, 2021 at 08:27:58PM -0600, enztec@gmx.com wrote:
> >> )off ends the apl session completely - i want to keep the ws open and just 
> >> end the script execytuib and then edit the script in directory (and move 
> >> around the '→0' or what ever can end the script execution - for debug) and 
> >> then )copy the edited script back into the ws and it runs until it hits 
> >> the '→0'
> >>
> >> Maybe something like ]NEXTFILE then.
> >>
> >> -k
> >>
> >>
>