Dear Jürgen, Thank you for responding. Please see my comments below:
On Mon, Mar 31, 2014 at 9:12 AM, Juergen Sauermann < [email protected]> wrote: > Hi Blake, > > 1. currently there is only bug-apl@gnu,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
