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

[Juergen Sauermann]

Hi,

I believe there is no reasonable way how a script that uses the ∇-editor
can know how a possibly already existing function looks like. In other
words, appending in a script is, in practice, always a mistake.

I have therefore changed the ∇-editor so that it always clears a function
if executed from a script (hope this works).

This also simplifies the design of libraries because it does no longer  
require to
)ERASE foo before every ∇foo.

/// Jürgen


On 04/26/2014 05:00 PM, Kacper Gutowski wrote:
> On 2014-04-26 21:15:43, Elias Mårtenson wrote:
> > On 26 April 2014 20:52, Kacper Gutowski <address@hidden> wrote:
> > > ∇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].
> > I don't like this at all. I want my APL source files to define functions as
> > such:
> >
> >        ∇Z←foo X
> >        Z←X+1
> >        ∇
> >   
> > I would also like to be able to reload the source files fully after making
> > major changes (a simple change can be pushed by simply pressing C-c C-c on it
> > of course). This means that I don't want to have any unexpected behaviour when
> > doing so.
> I agree this is much better when you consider legibility.
> My “solution” is indeed terrible and, in fact, doesn't even work
> correctly because it would fail to delete ending lines if new
> definition were shorter than old one.
>
> But still, I don't like the idea of doing things differently
> because this means that it no longer has the semantics of reading and
> executing files as scripts, but rather it is a fancy format for workspace.
> It's undeniably useful, but distinct from what I expected.
>
> But in the end, like I've written, in case of ∇ it may not be a problem.
> I don't like it, but I don't really see how could it get in the way.  In
> fact, redefining functions from scratch is closer to what you would expect
> from usual scripting language (but I'm not going to postulate removal of
> ∇-editor altogether).
>
> -k