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
<[email protected] <mailto:[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
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
[email protected] <mailto:[email protected]>
