Re: [Bug-apl] Concerning libraries

[Juergen Sauermann]

Hi,

I have it already on my TODO list to make )LOAD and )COPY aware of the format
produced by )DUMP (which is the same that apl -f can read back and it is apl code).

/// Jürgen


On 04/03/2014 03:31 PM, Elias Mårtenson wrote:

How about simply adding a way to )COPY in the content of a file which is not a previously dumped workspace, but rather a file that contains APL source code? I definitely prefer to edit files than storing everything in a workspace (also, it's easier to track things in the version control system that way).

Perhaps )COPY could simply check the extension to see if the file is a .xml or .apl? Or perhaps an alternative command )COPYAPL? )COPYSOURCE? Something else?

Regards,

Elias

On 3 April 2014 20:19, Juergen Sauermann <address@hidden> wrote:

Hi Elias,

I see. There are basically 2 cases:

1. a library entirely written in APL. In that case you would package the variables and functions
belonging to a lib into a workspace and )SAVE it. The user of the lib would then )COPY it into her
worksapce and thats it. Namespaces do not solve name conflicts but rather move them do a differen
level. In the old days people solved that by naming conventions using the ∆ character like mylib∆foo and
myvar∆data. I'm not really sure if replacing ∆ by . is really worth the effort (and the incompatibilities since
namespaces are not defined in any APL standard).

2. a library containing APL code and other stuff. The APL part can still be handled like 1. The problem is that
the other stuff cannot be shipped in binary form because unlike in Windows that would not run on all machines.
So either you need a language that can be interpreted directly (_javascript_, php, etc) or you need to compile it.
In our context (GNU/linux) compiling  most likely means autoconf/automake to deal with different platforms.
The automake can also handle the installation for 1. above so that the user does only the ./configure, make,
and make install steps for the library.

This can be further simplified by putting the lib into the GNU APL source tree, but that will not scale long term.
We could instead provide a header file declaring the functions that the library can use and then you can build
the lib "out-of-tree" as they call it for the GNU/linux kernel. The advantage of "in-tree" is that problems due to
changes in the interface between GNU APL and the lib become immediately visible. A disadvantage is that
the chance of build errors increases with every lib in-tree.

/// Jürgen

On 04/03/2014 01:51 PM, Elias Mårtenson wrote:

I think that perhaps we are using slightly different terminology which causes a slight confusion. Please allow me to clarify exactly what I mean:

When I say "library", what I mean is nothing more than a way of writing, delivering, loading code that can be used by other developers. This code could be APL in one or more files, it could be native code, or both for that matter.

That's really all I mean. Today, it's practically impossible for me to actually deliver my SQLite stuff in a form that other developers would find useful. Especially since it consists of both C++ and native code, but even for a library written in pure APL this would be difficult.

Now, there are more than one reason why it's difficult: one reason is that it's difficult to load a file of apl code into the running interpreter. Another reason is because of a lack of namespaces, which I mentioned in my previous mail. Of course the namespace issue can be worked around using prefixes like is usually done in Emacs Lisp which also lacks namespaces. But, proper namespace support is really useful when loading more than one library.

Regards,
Elias

On 3 Apr 2014 19:14, "Juergen Sauermann" <address@hidden> wrote:

Hi Elias,

The axis can be any APL value, so you can use a string or some structured context
as axis argument. I believe there should still be some structure so that people can
deal with different libraries. The idea of using an axis is that the axis contains information
about a function while the normal left and right arguments are passed as parameters
into the function.

We could also think about passing the APL name (i.e. the right argument of ⎕FX) of the function
to the function so that you can share the same library under different names in APL and every
name could call its own functions.

Regarding libraries, I have seen a strong need for that for years. But looking at the relatively
small community of GNU APL (compared to commercial vendors) we need libraries that are
useful also for other APL interpreters. I also think that shared libs in the form of .so files are
too cumbersome to be used as libraries, I see native functions more as wrapper functions in
order to interface 2ith libraries written in other languages.

/// Jürgen


On 04/03/2014 09:43 AM, Elias Mårtenson wrote:

As previously mentioned, I'm currently hacking away at SQL integration. Like all native libraries in GNU APL, the system is accessed using a function number together with the variable that is bound in the ⎕FX call.

There are, however, two limitations that I would like to see addressed:

First of all, one might want to use more than one function since remembering the function numbers is a bit ugly. Secondly, one might not want to implement all of the functionality in C++. Parts of the code would be much better written in APL itself.

Thus, we need the following:

• A way to load APL code packaged in a library (the APL code initialiser could do the necessary ⎕FX calls to load the native code, if such exists)
• A way to separate symbols in different namespaces. If two libraries define functions or variables with the same name, there would be problems.

Ideally, I'd like to be able to do something like:

)LoadWhatever 'SQLite3'

db ← SQLite.init '/path/to/database'

result ← db SQLite.query 'select * from foo'

SQLite.close db

(the above shows what my current SQLite implementation would look like if we had these features)

The )LoadWhatever command would load APL code in a similar way as the -f flag does when starting the interpreter.

About namespaces, here's a video about them in Dyalog. It's a pretty good idea: http://www.youtube.com/watch?v=XS5Hekf9a9I

Regards,

Elias