Re: Tokenizer error

[Dr . Jürgen Sauermann]

    Hi enztec,
      
      I see. If I look back at your example, i.e.
    
    apl_exec(')copy aa.apl');
    
    then it looks as if the
      problem is caused by the script aa.apl itself and
      not primarily by apl_exec() itself. The purpose of apl_exec()
      is to execute a
      single APL _expression_ in a somewhat atomic fashion. In contrast,
      )copy apl.aa asks for the execution of an entire APL script
      which is
      a completely different story.
      
      It is not entirely impossible to define or modify APL functions
      via apl_exec(),
      but )copy of other APL scripts is apparently not
      supported. The ISO standard
      defines 4 input modes of an APL interpreter, called execute,
      quad input,
      immediate-execution, and defined-function-control
      (aka ∇-editor).
      apl_exec() performs the first of them, i.e.  immediate-execution but
        cannot change to e.g defined-function-control
      as you attempted in 
      your example. You can still define or modify functions e.g. using
      ⎕FX or
      lambdas. As far as APL scripts are concerned, it seems like this
      is possible
      as long as they remain in immediate execution mode. I would also
      assume
      that the designer of libapl was not expecting that apl_exec()
      would be
      used in the way you do. I am also somewhat surprised that 
    apl_exec(')copy
          aa.apl'); did anything.
      
      Best Regards,
      Jürgen

On 7/30/22 12:45 AM, enztec@gmx.com wrote:

> Hi  Jürgen,
>
> apl_command gives the exact same Tokenizer error as does apl_exec with )copy with the only difference being that apl_command does not output the usually apl command result output without assigning it to a variable and outputing it (or writeln/printf/printf directly)
> )clear   CLEAR WS
> )copy   DUMPED 2022-07-29  13:15:37 (GMT-6)
>
> apl_exec(')copy /caf/rseq.seq');
> DUMPED 2022-07-29  13:15:37 (GMT-6)
>
> apl_command(')copy /caf/rseq.seq');
> [no output]
>
> var b : ansistring;
> b := apl_command(')copy /caf/rseq.seq');
> writeln(b);
> DUMPED 2022-07-29  13:15:37 (GMT-6)
>
> there is no difference between apl_command and apl_exec when working with )clear )copy )si )wsid etc in my code besides what is mentioned above
>
> i tested the exact same code with python3 libapl and c libapl and get the exact same complete behaviors and times as with fpc libapl in all respects especially with the )copy behavior copying a ∇fns header)
> (all require ⎕pw←0 in UCS_string.cc but python3 and c not requiring ⎕pw←80 in the main pgm before executing a )copy like fpc does)
>
> ---
>
> if you look at the times below - libapl is the way i need to do my apl coding
>
> when i run your code    (a,¨b)⌷¨⊂ar    1 time i get the following times in the stated various apl environments
>
> in fns in apl ws   111 msec
> in an apl executable script  110 msec
> fpc executing apl script  110 msec
>
> libapl c    59 msec
> libapl python3 60 msec
> libapl fpc  59 msec
>
> enztec
>
>
> On Fri, 29 Jul 2022 20:18:59 +0200
> Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:
>
> > Hi enztec,
> >
> > as I explained earlier, you must not use *apl_exec()* with APL commands
> > (such as*)COPY* ).
> > Use *apl_command()* instead, e.g.
> >
> > *apl_command(')copy aa.apl');*
> >
> > Best Regards,
> > Jürgen
> >
> > On 7/29/22 6:51 PM, enztec@gmx.com wrote:
> > > Hi,
> > >
> > > what about this error from :
> > >
> > > apl_exec(')copy aa.apl');
> > > where aa.apl contains the fns header ∇prep (the closing ∇ seems to not cause any problems at this point)
> > >
> > > SYNTAX ERROR+
> > > Tokenizer: No token for Unicode U+2207 (∇)
> > > Input: prep
> > >
> > > enztec
> > >
> > >         
> >       
>