TOtosh·Jan 13, 2024Submission
Apltail: APL Compiler targeting a typed array intermediate language
2 points · Open discussionmelsman
apltail
Standard ML2016–2024
melsman / apltail
apltail
APL Compiler targeting a typed array intermediate language
4Distinct people
7Mentions
0Explicit recommenders
220GitHub stars
What to know before exploring
What it is
APL Compiler targeting a typed array intermediate language
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- peportier/jelm · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year7 dated mentions
Observed mentions: 2016-06-23 18:59:52 UTC to 2024-01-13 14:02:57 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
7 sourcesAPL Compiler Based on Tail (Typed Array Intermediate Language)
62 points · Open discussionI like the confluence of ML and array languages happening right now. I know Pandas and NumPy are their offspring, but I like the array-oriented PLs. An ELM (Extreme Learning Machine) in J [1], CNNs in APL [2], and APL-to-GPU toolchains like Futhark/apltail [3,4]. I'll have to look at shapeRank.
[1] https://github.com/peportier/jelm
[2] https://dl.acm.org/doi/10.1145/3315454.3329960
[3] https://futhark-lang.org/blog/2016-06-20-futhark-as-an-apl-c...
[4] https://github.com/melsman/apltail/
In APL in its modern state (2020)I am playing with and learning April[1], a subset of APL that compiles to Lisp. It is a blast for me, because I had programmed a bit in Lisp in the 90s, and then I found J around 2011/12. I always loved Lisp, and I didn't really get into Clojure, although it is a nice language. I had heard of APL when I had my Commodore PET 2001 in 1977 and my Vic20 later, but I never got to play with it. Once I did back in 2015, and the APL characters resonated with me (hard to find keyboard input workarounds etc.) because I was free of the associations of ASCII and the symbols made sense as I learned it a bit in their graphic representation and function. I have dreamed of having a real, modern Lisp Machine, so maybe I can get some of that with Mezzano. I am not sure how hard or easy it would be for April's creator, Andrew Sengul (##phantomics) to swing
Read the rest
that, but I would participate in a crowdsourcing of it (on The Framework notebook[2] would be the icing on the cake!). I don't know enough of Mezzano to say how vialbe it really is, but I am hoping! I didn't quite get April right away, but I am really starting to appreciate it (with Andrew's help, and the APL community). Andrew's 'Why April' section, poetic and seemingly hyperbolic, is ringing less hyperbolic and more true as I get to know this twisted marriage of PLs: Lisp's legacy, tons of libs, emacs/slime, debugging, and parentheses, yes those beautiful things, to handle all the "front end" programming you could ever need, to feed the array-munching and alchemy of APL. And what about Python? I refer all Pythonistas to take heed of their and MIT's sinful choice to worship the serpent and casting us out from the garden of Lisp! Just read Milton's Paradise Lost, Book X, around verse 550-ish ;)
Machine learning which is heavily based on arrays or array math in their implementation, hence the popularity of libs to handle them like Pandas and NumPy (inspired by J, by the way. Ask Wes McKinney), has some nice nuggets or implementations of an ELM (Extreme Learning Machine) in J called 'JELM'[3], CNNs in APL[4] with some benchmarks, or getting APL into optimized GPU code via Futhark[5] and apltail[6]. And under some of those covers is Haskell as a treat!
Ah, yes we live in interesting times!
A link to an HN post in 2020 by Andrew:
[0] https://news.ycombinator.com/item?id=24434717
[1] https://github.com/phantomics/april
[2] https://frame.work/
[3] https://github.com/peportier/jelm
[4] https://dl.acm.org/doi/10.1145/3315454.3329960
[5] https://futhark-lang.org/blog/2016-06-20-futhark-as-an-apl-c...
[6] https://github.com/melsman/apltail/
Milton reference for the pious (with no parentheses;) or proper line breaks, sorry!)
Now Dragon grown, larger then whom the Sun
Ingenderd in the Pythian Vale on slime,
Huge Python, and his Power no less he seem’d
Above the rest still to retain; they all
Him follow’d issuing forth to th’ open Field,
Where all yet left of that revolted Rout
Heav’n-fall’n, in station stood or just array,
Sublime with expectation when to see
In Triumph issuing forth thir glorious Chief;
They saw, but other sight instead, a crowd
Of ugly Serpents; horror on them fell,
And horrid sympathie; for what they saw,
They felt themselvs now changing; down thir arms,
Down fell both Spear and Shield, down they as fast,
And the dire hiss renew’d, and the dire form
Catcht by Contagion, like in punishment,
As in thir crime.
APL (and J by extension) are more tricky to parallelise than you might expect. The frequent reliance on boxing leads to irregular pointer structures, and the absence of compile-time type information makes it hard to generate code at all. APL is usually based on efficient implementations of primitives, but that is certainly too fine-grained to be sufficient for bandwidth-starved devices such as GPUs. I contributed to an APL-to-GPU compiler[0], and it was hard to make it work on more than a small (well-behaved) subset.
[0]: https://github.com/melsman/apltail
In Manipulate Functions with the J LanguageTrue, and as hardware keeps evolving towards array-based setups like GPUs/ASICS with FPGAs and other hybrids, languages like J/APL/K fit them like a glove.
Using qdb from Kx or Jd for J, both columnar databases with billion row operations on capable vector-processing hardware is the modern realization of this type of computing.
These languages are not currently too popular, but I think a cousin of theirs will come on the scene and really light things up. Some current attempts at newer GPGPU targeted languages have popped up these past few years [1, 2, 3, 4].
The difference between these array languages and something like NumPy and other libs to add array processing and better numerics, is that the columnar databases or stores, have the array language built-in; you can abstract out, but if you program with them, there are no onion layers b
Read the rest
etween you and speed and processing.
[1] https://github.com/melsman/apltail/
[2] http://futhark-lang.org/index.html
[3] PDF - http://www.elsman.com/pdf/array14_final.pdf
[4] PDF - http://futhark-lang.org/publications/fhpc16.pdf
APL compiler targeting a typed array intermediate language
123 points · Open discussion