Re: [Bug-apl] Questions about GNU APL

[Juergen Sauermann]

Hi Blake,

i did not mean to say that every APL programmer should write her own file system interface,
or that component file systems are not useful. What I was after is the way such a file system
is integrated with GNU APL.

My current model is that of C/C++. There you have the core language, say C, that is comparable
to GNU APL. Then you have libraries for everything else including different databases, graphical stuff,
math, and the like. These days the libraries together are far bigger than the languages, and it is the
libraries more than the language that makes C/C++ usable everywhere.

If we would use ⎕xx functions for integrating a component darabase (for example) then the API (i.e. the ⎕xx)
function would become part of the GNU APL core language. That is not wise for a number of reasons:
documentation, maintenance responsibility, modularity to name a few. It also makes programs using them
less portable (even the encoding of the character ⎕ is different on different APL systems).

The reason why I mentioned GNU APL native functions is that they are the intended mechanism to extend
GNU APL (or in the above context) to build libraries that can be used (i.e. called) from GNU APL. And, unlike
⎕xx functions, they can be replaced by wrapper functions written in APL to port APL programs to other
interpreters without the need to change every call of ⎕xx.

The emacs mode written by Elias is an example of such a "library". It allows us to please emacs users
without any (well - almost) impact on GNU APL itself. I believe a database interface should be done in
the same fashion. So if you would like to provide a component database for GNU APL, please feel invited
to do so. If there are functions missing in GNU APL then I will try to provide them. That was kind of the
work-split between Elias and myself in the case of emacs mode.

Best Regards,
Jürgen Sauermann


On 03/31/2014 05:00 PM, Blake McBride wrote:

Dear Jürgen,

Thank you for responding.  Please see my comments below:

On Mon, Mar 31, 2014 at 9:12 AM, Juergen Sauermann <address@hidden> wrote:

Hi Blake,

1. currently there is only address@hidden,org that deals with everything
related to GNU APL. The posting frequency is not that high, so I think
a separate list makes little sense. It is perfectly OK if you post discussions
and other non-bugs to bug-apl.

It was unclear to me that bug-apl was actually an email list.  From your docs I gathered that that address was just email to you.  The bug-apl list is surely adequate.  My only suggestion at this point is to make the included documentation make it clear that that address is a list.  Just a suggestion...

(more below)

 

2. I could answer that if I knew exactly what component file is?

Historically, APL component files referred to a mechanism that allows the user to store arbitrary APL arrays in a data file by use of an index or record number.  Thus the component file acted like an APL vector that externally stored.  You could assign values to indexes or record number within the component file.  This component file system is somewhat described in the standard you refer to (is13751.pdf, Annex A., Page 254).  It is better defined and explained in the "Dyalog APL - Tutorial" you refer to in the section titled "Component Files" on page 536.

Every APL I have ever used had a component file system.  I don't know how you could build a business application without one.  You always have data you need to persist.  While component file system are a bit crude, a keyed file system is much more useful and can be built on top of a component file system.

Keyed file systems work like component file systems except that instead of an index (or record number) used to access the arrays, a string or integer key is used.  This would also include the ability to read next and prior record in key order.  This made APL highly usable for business applications!

(more below)

 

Is that the
⍐, ⍗, ⍇, and ⍈ functions from APL68000? Anyway, I would like to keep
file systems, databases etc. out of the core GNU APL because the preferences
and requirements of different people are likely to be very different.

Not sure I agree.  File systems store generic data and can be used pretty arbitrarily.  Properly designed, it is no less generic and applicable than any other APL operator.

(more below)

 

However such functions are needed in real life and the intended way to interface
to such functions in GNU APL are native functions (as opposed to introducing new
⎕xx functions or using shared variables).

Although this is do-able, it is a huge burden to require each user to write his own file system interface, specially when it is very largely (if nut universally) needed.  If designed thoughtfully, it would be very widely and very generally useful.

While a lot of fun, GNU APL is not useful to me without the ability to persist data.  I really appreciate and respect what you have done.  I think you are 98% there.  Adding a component and keyed file system could blow the walls out of APL use and could possibly usher in the second coming of APL IMO.

I am an expert in C, and I have a lot of database experience.  I've even written a few Btree-plus file systems (in APL and C).  On the other hand, I don't know anything about GNU APL's internals.  If you are interested, perhaps we can work together to add this feature.

Thanks again for a lovely system!

Blake McBride

 

3. I believe that A. - D. are of general interest. Is is just a question of how to provide
and maintain them. My view on this is that APL functions and variables should be
stored and published in a vendor-independent format that can be easily imported
into APL and easily exported out of APL, The format shall be human-readable and
easy to copy-and-paste from web pages etc. The new )DUMP command of GNU APL
is an attempt into that direction.

/// Jürgen

On 03/31/2014 06:51 AM, Blake McBride wrote:

Greetings,

I started programming in APL in 1980.  I programmed in it for about five years.  I have a lot of fond memories.  I hadn't been too interested in APL for a long time because it was controlled by vendors who could go out of business at a moments notice.  I couldn't base anything on it - until now!

I am currently running on Linux.  I installed GNU APL 1.3 without any problems.  Seems to work so far.  Very nice!

I happen to have an APL keyboard that also seems to work fine.

I have some questions that I would appreciate if you can answer as follows:

1.  Is there a mailing list for the public to interact regarding GNU APL?  (If not, it would be very nice!)

2.  I started out using component file.  I later moved on to keyed files (from TSR).  I never really used shared variables.  Does GNU APL have component and/or keyed files?  This is pretty critical.  If not, is one planned?

3.  I wrote the following in portable APL.  I think I still have the code.  Is there any interest in it?

A.  Multi-user keyed file system on top of a component file system.

B.  APL code editor

C.  Advanced formatter that includes things like commas in numbers, floating dollar signs, parens around negative numbers, fixed decimal places, etc.

D.  A large set of various functions that make building applications in APL much simpler.  Many are clean-room implementation of TSR's old libraries including user IO with error checking, calendar/Julian date routines, and many more.

Thanks!

Blake McBride

address@hidden