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]>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]> > 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 >> >> >> >
