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"
<[email protected] <mailto:[email protected]>>
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
