Dyalog Forums

I have moved the APEX compiler source code management to git, and am trying to use
]link, so that I can do all editing using vi/vim or other host-standard editor.

Are there any best practices documents or tutorials available for ]link,
and/or for maintaining large, APL-coded-ish systems in, or near, Dyalog APL?

In my case, most of the relevant compiler phase code resides in tree-structured
APL namespaces within the compiler framework. This works quite well, and
provides a clean separation of phases, such as syntax analysis,
static-single-assignment translation, data flow analysis, and code generation.
In particular, ]dbuild does a good job here, and is simple enough to understand
when returning to a project after a long hiatus.

However, some parts of the compiler, such as code generator "fragments",
are maintained in native text files. This is convenient, and it also facilitates
extension of the run-time system by non-APL users.
These code fragments differ for each code generator (SaC, Plural, SISAL);
they reside in git within the folder for the relevant code generator, e.g.,
Plural/fragments/takedrop.frg

This leaves me with a few unanswered questions about tool generation:

1. Generating the compiler as a namespace tree seems reasonable. A workspace
feels old school, particularly when I want to invoke the compiler on, e.g.,
my own BelchFireAnalytics system.

What is the recommended way forward on such tool vs. app systems?

2. Having code fragments, or other host-system files in git is mandatory
for one's sanity. However, it is not clear to me how the equivalent
of a Makefile or dyalogbuild file should be designed to facilitate
similar structure within a system that is intended to be shipped to
users, perhaps without git or the file tree structures that ]dbuild
wants.

What are people doing now, and what are the benefits and costs
of those approaches?

Bob

Very big questions with no easy answers. I think the questions are much bigger than best practices with LINK.

I can tell you what I am doing: https://github.com/the-carlisle-group/Dado

In particular see the documentation/user guide at the wiki: https://github.com/the-carlisle-group/Dado/wiki

The general ideas may be useful.

Regarding "a workspace seems old school", I think workspaces are still extremely useful when one is distributing the interpreter with the code in a neat installation package. However, when the recipient is providing his own version of the interpreter it of course gets dicey. The last commit to the above project was an attempt to create a single namespace script of an arbitrary complex tree of APL code. Its very fast to create, and very fast to fix using ⎕FIX. Unfortunately Dyalog injects all sorts of references and pointers that can and will mess up an app of any complexity - a decision made long ago that I think was a mistake. I asked them a while back to look at maybe adding a left argument that would change the behavior, removing the intrusiveness, and just doing what is asked instead of making assumptions about things.

Bit of a side issue here but I've seen many attempts at defining coding standards over the decades.

I followed Paul's link and was attracted to this: https://github.com/the-carlisle-group/D ... Dyalog-APL

I hope Paul won't mind my referring to this as the best set of prohibitions from a libertarian I've ever read - and the best set of coding standards - although I must admit to having broken a fair number of them on numerous occasions.

The article is interesting. There are many things I don't agree with, both as a developer and as a former manager of a group of 40 Dyalog developers. As a basis for a discussion, though, it is a well-thought list.
I find there's something lacking and that I would consider more important than all the rules listed. It's hard to put in words, and I've had a lot of trouble to convey what I mean every time I tried to explain it in the last few years.

Never mind the presence or absence of comments, code should be meaningful. And by meaningful I mean that it should be able, even looked at in isolation, to describe its data and the manipulation is being done on it.
For instance: 99.9% of the time the esthetically pleasing combination "⍎⍕" means "I have no idea whether I am getting a number or a string here, but I want a number". This is... bad. Very bad. So is a function which begins with "arg←⊃⍵" which means "I have no idea why I am being called with something that is not a scalar sometimes, but I'll cope with it". No, that's bad.
This argument can be extended and applied to situations that are much more complex. Code can be trivially written, respect all the stylistic rules, and still be completely opaque. Because the person who wrote it did not have a clue, was in a hurry or a million other valid reasons.
Writing meaningful code is hard and is subjective. But unless people are exposed to the concept they'll keep writing safe, clean, fast and completely misleading code.