Re: [Bug-apl] SQL interface needs a workspace

[Elias Mårtenson]

Well as for the SQL support, it certainly would be useful to have it shipped as part of GNU APL. The main reasons for me not pushing for that yet is that the workflow is a bit painful. There was some discussion a few months ago about external contributions to the source repository, but it's complicated by the fact that Jürgen is actually not doing his development against the official repository. The official one takes patches in chunks from the development repository.

All of this is part of the reason why I'm not pushing for this yet, but instead await the outcome of the standard library discussions and implementations. If there was a way for a user to simply say "get me the SQL stuff" and everything was downloaded (and possibly compiled) and installed automatically, then that would be ideal. We're some way away from that right now though.

Until then, I don't personally intend to do any work on the packaging, but if you want to contribute, go right ahead.

Finally, about extensions, I have actually considered implementing a new language (on top of Common Lisp most likely) that implements the essence of the APL syntax and functions but with Lisp integration. And rest assured that this thing will not be called "APL". :-)

Regards,

Elias

On 16 May 2014 00:06, Blake McBride <address@hidden> wrote:

Dear Elias,

Notwithstanding my rant about nested arrays, yes, I do agree with Jürgen.  Once you drift from the standard, you no longer have APL, you have XYZ.  Creating XYZ is fine and great, it's just not APL.  And, you probably should't call it APL.

I am very much in favor of enhancement to GNU APL over the APL standard so long as those enhancements do not conflict with or limit existing standards.

Having all sorts of random extensions to GNU APL peppered all over the net is not good IMO.  APL is rare enough as it is.  Adding many undocumented steps and requirements will only serve to reduce the number of new users.  It is an unnecessary barrier to entry.  IMO GNU APL should have a contrib directory.  Contributors like you should be given SVN write access to your package under the contrib directory.  Your SQL library in particular is extremely valuable and perhaps it should just be added to GNU APL.

Blake

On Thu, May 15, 2014 at 10:43 AM, Elias Mårtenson <address@hidden> wrote:

Well, I never said you can't use a workspace. Right now everything about the libraries and packages are very much in flux, which is why I have not spent much time thinking about distribution.

There clearly needs to be a nice, encapsulated, way to distribute libraries with a native component. I think we'll deal with that once the pure APL package system is done.

Finally, I think we simply have to agree to disagree on the value of various traditional APLisms. There are plenty of things I would like to see modernised, but I haven't even mentioned most of those because there are much more important things to deal with. Besides, Jürgen's opinion is generally closer aligned to yours than mine, so I'm clearly outnumbered. :-)

Regards,

Elias

On 15 May 2014 23:37, Blake McBride <address@hidden> wrote:

Dear Elias,

I will add the SQL workspace to my upcoming keyed file system.  Should I add a README for your SQL library to my keyed file package too?

Regarding workspaces and their opaque format, this is exactly the same argument as my nested array argument.  Are we going to debate and ignore the IBM APL standard, or support it?

BTW, your postgresql fix works great.  Thanks!!

Blake

On Thu, May 15, 2014 at 10:18 AM, Elias Mårtenson <address@hidden> wrote:

Actually, I have already mentioned to Jürgen that we need some way of specifying a default serach path for )LOAD and friends. However, I have not seen it as particularly important yet since we don't have a completed package manager yet.

I personally dislike workspaces and I know I'm not alone in the desire to have plain source files instead of an opaque format. Therefore, I don't really have any particular drive to make it. But, go right ahead and make one if you feel that would be useful.

Regards,

Elias

On 15 May 2014 22:30, Blake McBride <address@hidden> wrote:

Greetings,

I am in the process of writing a proposed README.txt file for the SQL interface to GNU APL.  That package comes with a file named sql.apl that is a shell script to startup GNU APL with the SQL shared library and APL routines already loaded.

IMO, that method of loading it has a few problems.  It only works from the distribution directory unless the user knows (without understanding the pieces) what paths need to be changed - which is undocumented.  It is further complicated by the need for the startup path of APL and its relation to the workspaces directory used by APL.  All this is way too much for a newbie.

The second problem is that that script pre-loads needed APL functions.  Again, when a newbie loads their own workspace, they will lose the APL routines.

My suggestion, without necessarily removing sql.apl, is to have that package include an actual workspace that can be loaded.  That workspace would be a copy of sql.apl except that:

1.  sql∆∆load_library world be renamed to SQL∆LoadLibrary to be consistent with the other functions in that workspace.

2.  SQL∆LoadLibrary will take an argument specifying the full path of lib_sql.so rather than having it hard-coded.

Along with some documentation, I think this will make the SQL library a lot easier to use for newbies.

Thanks.

Blake