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