Hi Tortus,
welcome to GNU APL and thank you for offering your help.
Let me first explain what I believe is the current state of the project.
The most part of the development (in terms of
new C/C++ code) is done and I have currently no more ideas what else
could be useful. For that reason adding
considerable amounts of new code is not something on our TODO list. Most
of code changes that I am still doing
are about restructuring the exiting code without changing its function.
In the early years of the GNU APL development
I created relatively huge amounts of C/C++ code in a very short time and
often used hacks for quickly implementing
functions that looked not essential at that time. These days, when I
discover such code (often when fixing bugs)
I tend to re-implement it in a cleaner or easier to understand way.
Helping in this area means to look at the existing
C/C++ code and finding problematic or obscure parts. But be warned: the
code base is quite large (around 110,000
LOC) and your work would be hardly visible to the outside world which
could be somewhat frustrating. An interesting
job might be to improve the doxygen documentation in the GNU APL source
code. Even though the job is somewhat
boring, I believe it is a good start into learning how GNU APL works.
One subsection of coding is the development of (automated) testcases.
This area definitely deserve some
more efforts. Currently there are around 240 testcases in the
src/testcases directory. Every testcase tests a single
function of feature (APL primitives in most cases). Initially I wrote
one testcase per APL primitive (and the testcase
file is then named after the primitive). After some time I started
adding all examples that I came across either
int the IBM APL Language reference document and in the ISO standard. I
didn't do that too strictly, though, and
therefore there are still examples in both the IBM language reference
and in the ISO standard.
Therefore one job still to be done is to read these two documents and
create testcase files for not-too-trivial
examples from these two documents. The person doing that should not only
be fit in APL programming but also
have a grasp on APL itself. There are contradictions between the
language reference and the ISO standard and
the testcase designer should have a good judgement as to what solution
is the best.
Another task related to testcases is coverage and the like. GNU APL can
be ./configure'd to produce .gcov files.
After that, running *make test* produce these gcov files which can be
analyzed with the gcov program. That in turn
tells how much (and which) if the GNU APL source code was executed by
*make test*, i.e. by the testcases in
src/testcases. A separate job would be to create testcases so that the
coverage is increased. Be warned that
this is a major effort and external visibility is somewhat low (even
though you could put you name as a copyright
notice into the testcase files).
A completely different area is user documentation. One big problem that
I have is that I am not a native English
speaker which makes the documentation that I wrote look a little odd. A
review and rephrasing of existing user
documentation, primarily the doc/apl.texi file and the improvement of
the English language iin it would be a valuable
job to do. Along the same lines, already some years ago I started a
document named apl-intro which should be an
introduction to apl by examples kind of document. I used a somewhat cool
approach which uses GNU APL itself to
produce the output of the examples (and therefore the examples are
always correct). The document is in a half-finished
state and reviewing and finalizing it would be good. Even though I
started the document I don't insist to be
named as the author. Whoever undertakes to finish this document could
therefore become its author.
A final area that I always wanted to look into is APL libraries. I am
still convinced that the reasons why APL
has become a mere niche language is 2 mistakes made by the APL vendors.
Reason #1 is pricing of APL
interpreters (and GNU APL is an attempt to fix that, but came far too
late). Reason #2 is that lack of useful
libraries (combined with a lack of visibility of those that exist). All
successful languages that I know come with
(or have easy access to) libraries that solve the standard programming
jobs. In the 1970s some APL vendors
were boasting about the productivity of APL. But the lack of APL
libraries has rendered C/C++ more productive
than APL these days. I remember one vendor declaring FORTRAN a dead
language in the 1970s. They were
right as far as FORTRAN is concerned (probably laso due to lack of
libraries) but these folks are now a dead
APL vendor themselves). I believe that this topic deserves far more
attention. I have tried to start something
at http://www.gnu.org/software/apl/Community.html but it hasn't really
taken off. Unfortunately I have no idea
myself as to how to improve this.
Now, if anything above might interest you then please let me know and we
can work out the details.
But other ideas are equally welcome.
Best Regards,
Jürgen
On 7/15/22 11:50 PM, Tortus Smash Stuff wrote:
Hello,
I’m Tortus, an aspiring APL programmer, and I’m interested in
contributing to this project, be it documentation or code, bug fixes
or adding functionality. Looking at the web-page, I’m finding it
slightly unclear as to where I could start. What sort of ways can I
help this project other than passively providing suggestions?
Thank you!
︹̤ρ
