Re: [Bug-apl] Bug: GNU APL does not call start_input after a )LOAD

[Elias Mårtenson]

From the Emacs mode's perspective, that would be perfectly appropriate of course. However, the native library module is, despite its name, not necessarily specific to Emacs. It implements a generic protocol that any external tool could use. It's not guaranteed that a user of the native module wants the other behaviours triggered by the --emacs flag.

Secondly, there may be other native libraries that also may want to be loaded as an "extension" (as opposed to a "library").

Thus, if you want to make extension loading into something that is specified on the command line, that's perfectly fine, but I'd prefer to see such feature be disjoint from the --emacs flag.

How about a --extension=/path/to/extension flag? (ideally, it would somehow need to be possible to specify more than one)

Regards,

Elias

On 13 May 2014 20:21, Juergen Sauermann <address@hidden> wrote:

Hi Elias,

wouldn't it then be easier for the user to load the emacs lib when --emacs is given?

BTW we could make --emacs an entry in the preferences file so that the user does not
need to give it on the command line every time.

/// Jürgen

On 05/11/2014 03:12 AM, Elias Mårtenson wrote:

Indeed it would fine to load it via a command, and it's perfectly acceptable to not be able to call it from APL. The Emacs library has very few requirements.

So, perhaps we should have two different types of native libraries? We could call them "native library" (with the existing semantics), and the other being, hmm… let's call it "extension".

Native libraries would then introduce a normal APL function and be subject to the usual lifecycle of any other function symbol.

Extensions would add one or more ]COMMAND's and not be affected by the symbols lifecycle.

I don't really see any need to even have the ability to unload an extension, so if that's complicated to implement it can be ignored.

Regards,

Elias

On 11 May 2014 00:33, Juergen Sauermann <address@hidden> wrote:

Hi Elias,

I see. So when would you like to load the shared lib? We could do it by )COMMAND or by a --command-line-option.
Sounds like you want it rather early, even before APL's immediate execution loop starts. That would be a
--command-line-option then. We could keep the rest (function names in libraries etc.) and just separate the
native function object. There would still be a native function object as such, but you don't see it in APL and you
can't delete it either. Of course you also can't call it from APL then.

/// Jürgen

On 05/10/2014 05:47 PM, Elias Mårtenson wrote:

First of all, sorry about the benchmark numbers. I thought I already sent them but I see now that I had forgotten about it. I'll do it tomorrow.

About the libraries, I see what you are saying. Having a library ID is definitely one way of dealing with this (I suppose the package manager can be used to pull it in if it's missing on the system).

However, the Emacs mode is different. A non-emacs user would not want to (and shouldn't) have the library loaded. Likewise, if I load a dump from someone who is not using Emacs, I don't want to lose the Emacs mode that I already loaded.

I think that the Emacs mode native library and others, such as the SQL one, are fundamentally different in the sense that the former attaches to the runtime session and never interacts with the programs the user writes, while the other is a "normal" library used by a specific program that only differs from a normal APL program by the language the library is written in.

The library ID system is definitely a good thing for the latter type of native library.

However, I believe a separate model is needed for the former type. In fact, the Emacs mode library doesn't even need a function entry point. I can imagine other libraries of the same type, though none as obvious as the editor integration stuff.

The former type need to load, stay in a single session, and never interact with the user in any visible way. This includes being included in a dump file. Even seeing the native entry point in the output of )FNS can be confusing, and I would really like to be able to avoid that one.

Regards,

Elias