|
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'
(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.
Regards,
Elias
|