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 <juergen.sauerm...@t-online.de
<mailto:juergen.sauerm...@t-online.de>> 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
