Language request: APL

[marnen]

What programming language should we add?

APL. It may seem like a weird phenomenon from the 1970s, but it has a lot to teach a modern programmer. I'm currently learning it, finding it extremely intellectually stimulating, and wishing it had an Exercism track. :)

What is the official website for the language?

I'm not sure there's one official website, but the APL Wiki is at http://aplwiki.com/.

Is this a language that comes in many variants? If so, which variant should we support?

There are several interpreters available, both open-source and otherwise. The main OSS implementation that I'm aware of is GNU APL, which is most likely what we should target, especially since it claims to implement nearly all of ISO 13751. Another possibility is to target A+, which is closely based on APL but is AFAIK not completely compatible with it; its interpreter is likewise OSS.

I understand that Dyalog APL is a popular proprietary interpreter, but I think it probably makes sense for Exercism to target an OSS interpreter if one exists and is sufficiently capable.

I'm not terribly certain of how great the differences are between these interpreters' dialects of APL, or how closely any of them adheres to the ISO 13751 standard.

Is there a testing framework available for the language?

Unit testing APL is kind of a funny idea, because of the nature of the language, which may explain why I've only found one unit testing framework: APLUnit. It's written for Dyalog APL; I don't know if it can run on GNU APL as is, or if it would need modification (I can try it and see, but haven't had occasion to do so yet).

Unfortunately, I haven't been able to find an xSpec-type test framework for APL.

Who will be leading the effort to launch the track?

I could initially, I suppose, but I'm a beginner in APL. I hope more experienced APL developers will join me.

---

If it is helpful, I can start trying to develop Exercism exercises for APL and see what roadblocks I run into.

[marnen]

Further info: https://github.com/ngn/apl is an APL interpreter written in JavaScript!

[NobbZ]

Doesn't APL make heavy use of special symbols that you can't (easily) enter on modern keyboards?

[marnen]

@NobbZ Good question. Fortunately, all APL symbols are part of Unicode, and APL keyboard layouts are available for all major operating systems, so this isn't much of an issue.

[kytrinyx]

@marnen I think APL would be a very interesting track for Exercism.

I think, before I bootstrap up a track, I'd like to see what an exercise would look like. Would you be willing to do a couple of experiments to implement a simple hello world exercise, as well as one slightly more complex one?

[marnen]

@kytrinyx Of course!

[marnen]

Hmm. This may be harder than I thought, because of the way APL works. APLUnit probably won't work on GNU APL, because it uses Dyalog's :if...:endif control structures, which aren't part of the ISO standard (which is what GNU APL implements). OK, fine, I could probably port it to GNU APL or write something similar (which, if I keep it to ISO-standard APL, should also run on the Dyalog interpreter), but there's another issue.

Apparently APL has the concept of a workspace, rather like a Smalltalk image, as the dominant metaphor for code organization. As such, there's relatively little notion of libraries that would be analogous to, say, Ruby gems, so even if I do write a testing library, I'm not sure how to load it. There is http://github.com/TieDyedDevil/apl-pkg, which is a package manager for GNU APL, but apparently it does enough OS-specific stuff that the maintainer only expects it to run on Linux. I don't know how hard it would be to get it to work on Mac OS or Windows; probably not too hard, but...

I'm still going to try to make this happen as time permits, but fitting APL into a modern ecosystem is surprisingly weird.

[kytrinyx]

@marnen this is tricky. I'm hereby classifying APL as esoteric purely on the basis of this discussion ✨

even if I do write a testing library, I'm not sure how to load it

Huh yeah. Distribution is solvable—we could make sure that the exercism CLI sticks the library on their machine. But that still raises the question of how to get it into their workspace. We could simply instruct them to copy it to the exercise (and then we could ignore it when we upload to the site or something).

[NobbZ]

According to Functional Geekery 76, there seem to be 2 APL derivates, which according to the interview are similar but not equal to APL. Perhaps those are a better fit for exercism:

• J language
• K language

[marnen]

@NobbZ There's also A+, which I mentioned above, and is probably closer in spirit to APL, from what little I know.

@kytrinyx:

Distribution is solvable—we could make sure that the exercism CLI sticks the library on their machine.

I would regard that as not Exercism's responsibility. None of the other Exercism tracks that I've played with (Ruby, Haskell, ECMAScript, Erlang, Elixir) does this kind of environment setup AFAIK. Instead, the client just downloads source code files and assumes that you have a suitable environment in which to run them.

But I suppose that if we don't have a usable package management system for installing the testing library, we could download it along with the first exercise. That just seems like something I'd rather avoid, though.

But that still raises the question of how to get it into their workspace. We could simply instruct them to copy it to the exercise (and then we could ignore it when we upload to the site or something).

Yeah...or if the package manager works, then we do it that way.

I doubt that this is an insurmountable problem, but APL was designed for a somewhat different sort of environment than has become the norm.

---

As a thought experiment, how would we implement a Smalltalk track for Exercism? Maybe there are some ideas to be found there...

[kytrinyx]

I would regard that as not Exercism's responsibility.

On the one hand... yes, but on the other hand we've already planned to implement it. I can't remember which tracks ended up having to copy/paste the same config files into all the exercises because we don't provide an opportunity for global setup.

Our planned solution looks like this:

1. Each track can optionally have a global/ directory.
2. Anything in the global directory (recursively) will be delivered to the CLI and placed in the root of the track directory, upon a specific command (e.g. exercism setup $TRACK).
3. We store a timestamp in Exercism's config that we called the setup command.
4. We pass an HTTP header on all download calls for a track that contains the last modified timestamp of the global directory.
5. The CLI can compare timestamps and if different, encourage the user to call setup.

[marnen]

@kytrinyx Oh, cool. So it would probably be somewhat sensible for me to put the unit testing library into the global directory (for compatibility with future tooling) and then use apl-pkg (assuming I can hack it to work on other OSes than Linux, and perhaps other APLs than GNU) in each exercise's test file in order to include the library?

[marnen]

...or maybe not. It sounds like the global download functionality doesn't exist yet? Is there a pull request or issue where I can track the status of that?

[kytrinyx]

@marnen If you can get this to work with the assumption that they have it in the root of their track directory, then I will go ahead and implement global. It's on my list, and is not hard, it's just not been a priority yet. This would make it so.

[marnen]

@kytrinyx Awesome, thanks! That also makes this project a lot more interesting for me.

In that case, I may first implement an exercise or two for Dyalog (a free version is available for non-commercial use), so that I can use APLUnit out of the box as proof of concept. Once that's done, I could see reimplementing for GNU APL. Does that sound reasonable?

[kytrinyx]

Does that sound reasonable?

That sounds most reasonable!

[marnen]

I'll see what I can do, then. This will actually be my first crack at real APL programming (I've done exercises, and even started to implement an interpreter, but that's it so far).

[marnen]

My free Dyalog license hasn't come yet (they have to be manually approved!), so I'm starting to play around with GNU APL for this. We'll see what I can do...

[marnen]

Well, well, well...we are in luck. It turns out that GNU APL has something of a testrunner built in. I didn't realize it sooner because it's kind of buried in the documentation, but the -T option contains a rudimentary test framework. I think this will be enough to get started (but I don't think it's part of the ISO standard, so we may need a proper test library at some point).

[kytrinyx]

Niiiice! This is exciting :)

[marnen]

OK, I've managed to implement a couple of exercises: check out http://github.com/marnen/exercism-apl.

[kytrinyx]

Wild. How about them triangle thingies! :-)

This is very cool.

[marnen]

@kytrinyx Glad you like it! So how would you like to proceed from here?

[kytrinyx]

It sounds like you're ready to make this official. If that's right, let's get you set up with a repository!

[marnen]

@kytrinyx Yes, let's do it!

[kytrinyx]

• [x] Run bootstrap script TRACK_ID=<id> LANGUAGE=<language> bin/bootstrap
• [x] Turn on Travis CI
• [x] Add exercism track topics
• [x] Add as a submodule to trackler TRACK_ID=<id>; git submodule add https://github.com/exercism/$TRACK_ID tracks/$TRACK_ID
• [x] Add the requestor(s) to the exercism/track-maintainers team
• [x] Update the team's parent https://github.com/orgs/exercism/teams/TRACK_ID/edit
• [x] Invite requestor(s) to the new team
• [x] Make a note of the new track and maintainers for the newsletter

[kytrinyx]

Quick question, @marnen, should we call it APL or GNU APL?

[marnen]

@kytrinyx I was wondering that myself. I'd hope that ISO-standard APL (which is mostly what GNU APL claims to implement) would run in any interpreter, but the tests are, for the moment, making use of GNU APL features that are not part of the ISO standard (specifically, the -T testrunner and the ⎕FIO system function for file I/O). So I think that, say, a Dyalog user would not be able to run the tests (but I can't confirm that till my Dyalog license comes through).

However, I'm trying to write all my code with as few deviations from the ISO standard as I can manage, in the hope that we can wrap all the nonstandard stuff in functions that can be differently implemented for different interpreters.

So we could call this track "GNU APL" and call a future Dyalog track "Dyalog", but that will scare off non-GNU APL users from running it even though they probably could at least get some use out of it. Or we could call this track "APL" or "ISO 13751 APL" or something, but that will annoy Dyalog and NARS users who expect it to run out of the box...

I just don't know what's best here.

[marnen]

BTW, just to be clear, I think this will need global implemented in order to work, because of the test utility functions that I wrote.

[kytrinyx]

BTW, just to be clear, I think this will need global implemented in order to work, because of the test utility functions that I wrote.

That should be fine.

I just don't know what's best here.

I don't either. Let's make it GNU APL and we can change it if we hear good reasons to later.

[kytrinyx]

Alrighty, the repo is ready for you. Sorry it took me a few days—I've been knee deep in the nextercism rewrite and only just realized I hadn't actually bootstrapped this.

The launch checklist is here:

https://github.com/exercism/gnu-apl/issues/1

Please submit individual pull requests with cohesive changes (e.g. documentation, CI setup, logo, individual exercises) to the new repo. I've given you commit access, so you can create branches right in the repo rather than creating a fork. Individual, smaller PRs will give us a few benefits:

• I can help catch things that should have been documented but weren't
• Ongoing development will be visible/transparent to others who are interested in following along
• It will be easier to go back in the git logs to figure things out

If you find things that are odd or confusing, holler. You can find other track maintainers in the chat room at https://gitter.im/exercism/dev (probably other rooms, too).

Welcome :heart: :heart: :heart:

[marnen]

@kytrinyx Great, thanks! I'll start working on it as time permits.