That's nice. I can't wait. When you, would it be possible to you add a tag to functions defined when loading such files? Could you set the tag to a string with the following format:
*/path/to/file!line* I.e. if the file loaded was /home/foo/bar.apl, and the function definition starts at line 123, the tag should be: */home/foo/bar.apl!123* This is used by the M-. (navigate to function definition) in the Emacs mode. I.e. one can place the cursor on the name of the function and press M-. and a buffer will be opened editing that file, and placing the cursor on that line. Regards, Elias On 3 April 2014 22:15, Juergen Sauermann <[email protected]>wrote: > 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]>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 >>> >>> >>> >> > >
