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