Re: [Bug-apl] is there a )copy ⎕fns like ⎕e x is )erase

[Kacper Gutowski]

On 2014-04-26 12:08:14, Juergen Sauermann wrote:
> I could make the ∇-editor aware that a )COPY is in progress and that
> functions shall be deleted automatically by the ∇-editor.

I like a lot that there is now a command that sources another file
raw, much like "." in shell or "#include" in cpp.  It's all that is
needed to make more complex programs/libraries in forms of
UNIX-ish-style scripts without relying on (hardly readable) workspace
files.

With this mindset I find any changes to behaviour highly unexpected
and I would probably report them as a bugs (unless properly documented
as an actual features, of course).  It might not be a problem in case
of ∇, but for updating already defined function it's an overkill as it
can be easily done explicitly by programmer like that:

∇mean[0]
  R←mean B
  R←(+/B)÷⍴B
∇

This can be )COPY-ied many times without any problems as it enters the
editor with a name only and then explicitly rewrites header line at [0].


As for implementing )EDIT-like routine, in other systems it launches
editor with a function body only, not ∇-editor commands.
So I think it might be a good idea to dump function's ⎕CR to a
temporary file and then launch external editor on it.  When done
editing, read it back, split by lines, and simply pass it to ⎕FX.
Maybe also ⎕EX FN when ⎕FX returns success with a different name,
and)COPY/)DUMP to destination file as appropriate.

The only drawback is that vi line numbers have 1-origin and this
can't be changed to zero.  And I'm not yet sure how to efficiently
slurp UTF-8 file as characters.  If I'm not mistaken, there isn't
anything in lib_file_io to help and it might require parsing UTF-8
in APL at the moment.
Alternatively, one could automatically wrap modified function from
file with #!apl and ∇name[0] … ∇ header and then )COPY it in, but
that would be ugly.


On 2014-04-26 03:08:59, enztec wrote:
>  fp←'r' FILE_IO[24] 'vi workspaces/',fn,' < `tty` > `tty`'

I guess, YMMV on other systems, but in my environment (linux) it
suffices to do '> /dev/tty', there is no point in running additional
command just to get current tty, and input redirection is superfluous
when doing popen 'r'.


-k