Hey Guix,

This packages up the J programming lanuage. The build scripts that upstream
provides are pretty hostile to package maintainers, so we have to jump through
quite a few hoops to get the build working.

I have had this in my personal, private channel for a while, tweaking it over
time, so I believe it works fairly well in practice. Here are the high-level
design decisions I have made:

1) Provide multiple J versions;

It is extremely common for J users to have multiple versions installed in
parallel since there are often major, breaking changes between
(non-patch-level) releases.

In addition, a very large fraction of J users keep the beta installed as well,
so I have elected to provide this too.

2) Bundle together all variants of the interpreter along with a
wrapper script that selects the most featureful one at runtime;

There are 3 versions of the interpreter, supporting different CPU feature-sets:
vanilla, AVX, AVX2. This package elects to build all these variants and
provides a wrapper script that launches the "most AVX-y" version possible at
runtime.

Essentially, this is trying to make up for upstream's lack of a fat binary.

3) Try to mirror the FHS standard for installation locations;

For the most part, J uses idiosyncratic defaults for where it looks for library
files and the like. This package elects to configure things so files sit in
more standard locations---e.g. runtime scripts sit under .../share/j;
configuration files sit under .../etc/j; etc.

4) Point the J package manager to $HOME/.j/<version>.

J maintains its own mini package repository for "addons", which are simply
officially-supported J scripts. This package sets things up so that these
packages get installed to .j/<version>/addons. In addition, other related
directories are gathered under .j/<version>.


Items on the TODO list:

1) Write an importer and create packages for J addons;

This is currently in progress.

2) Create a something like a jsoftware-union procedure to bundle up J with
user-selectable addons;

This is necessary since the interpreter looks for addons at a specified path.
We probably want to mimick something like texlive and provide both an "all
batteries included" package along with one where users can select which addons
they want.

3) Support more older versions of J.

J is open source starting with j801, so it'd be nice to have packages for the
entire j80x series too. Unfortunately, those use an entirely different set of
build scripts from the current j90x series, so it will require munging-work
similar to what we already have.


Cheers!