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, enz...@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 <m...@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, enz...@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