I already do pretty much this in the Android version. The Android APK contains libapl.so which is then linked from the Java code which drives the user interface.
Building libapl.so takes a bit of manual work right now, but in essence I configure the GNU APL source using the --with-android flag, and then compile and manually link the library together with some glue code. You can look at the source here: https://github.com/lokedhs/android-gnu-apl/tree/master/build-tools Regards, Elias On 30 January 2015 at 16:32, Dirk Laurie <dirk.lau...@gmail.com> wrote: > Dear Jürgen: > > I am tackling a (possibly ambitious) project to make bindings to GNU APL > 1.4 > that would allow a Lua program to create one or more APL workspaces, pass > strings containing APL code to them, and convert items from the workspaces > to Lua values. Since Lua is a component of LuaTeX, it would then be > possible to include APL code and the result of executing it in one TeX > document without leaving TeX. > > At present, I simply make one huge shared object file which also contains > all of GNU APL except main.cc. In order to satisfy external references, > I have needed to copy the code defining `void cleanup()` and `void > control_C(int)` as well as the five external variables in between to the > file defining the bindings. > > A more canonical way of doing the same would be to link to a library > `libapl.so`, but GNU APL 1.4 does not make such a library. Perhaps the > current suite of files `/usr/lib/apl/lib_template_F0.so` etc could provide > the equivalent, but I have not been able to discover a way of loading > those files sequentially in Lua, which requires each shared object file > to have no unresolved dependencies. > > Do you think there is any chance that a future release of GNU APL might > provide a library that would allow the embedding of APL functionality in > a different host program? > > Thanks for a very impressive APL implementation, and best wishes. > > Dirk Laurie > >
