DIdig1·Oct 31, 2021
There is also Harlan [1], which created a bit of buzz a couple of years ago. Sadly it is not maintained anymore...
[1] https://github.com/eholk/harlan
In Ask HN: Will there ever be a vendor agnostic GPU interface?eholk
harlan
Scheme2013–2021
eholk / harlan
harlan
A language for GPU computing.
12Distinct people
16Mentions
0Explicit recommenders
1.2KGitHub stars
What to know before exploring
What it is
A language for GPU computing.
GitHub
Where it is used
No documented product use was verified in the last source check.
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
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 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 year16 dated mentions
Observed mentions: 2013-07-01 15:03:28 UTC to 2021-10-31 18:47:35 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 |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 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 | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
16 sourcesHarlan: A scheme like language for GPU computing
2 points · Open discussionIn case you haven't seen the applications of nanopass compilers to do similar things, specifically harlan, here you go: https://github.com/eholk/harlan
In And now for something completely different: running Lisp on GPUs [pdf]I like CEPL a lot too, but I agree, it doesn't address the OP's pain points.
I am not enough of a gpu guy to know, but I thought that was what Harlan [1] was trying to address. It had used miniKanren originally as a region and type inferencer.
[1] https://github.com/eholk/harlan
In Weep for Graphics ProgrammingAll the arguments against the CL-style macros are stemming from the fact that it's far too easy to get into a total mess with them, simply because of their infinite flexibility. Yet, if you follow some very simple rules, you'll get the opposite.
Firstly, macros must be simple and must essentially correspond to compiler passes.
E.g., if you're implementing an embedded DSL for regular expressions, one macro expansion pass should lower your DSL down to a syntax-expanded regular expression, the second macro would lower it into an NFA, another one would construct an optimised DFA, and then the next one (or more) would generate the actual automaton code in Lisp out of the DFA.
The best possible case is when your macro pass can be expressed as a set of simple term rewriting rules. And most of the transforms you'd find in DSL compilers can actual
Read the rest
ly be represented as such.
Of course, there is also an alternative style, which may be preferable if you have debugging tools for designing your compiler passes at least equivalent to the Lisp macro expansion debugging. You can simply write your entire DSL compiler as a single function, and then wrap it into a macro, as `(defmacro mydsl (&rest args) (mydsl-compiler args))`.
This way, the same compiler infrastructure can be reused for an interpreted or partially interpreted version of your DSL, if you need it. Still, all the same rules apply to how the passes are implemented in that compiler function.
Another very useful trick is to make your DSLs composable, which is easy if you split your compilation pipeline into separate macro expansion passes. Multiple DSLs may easily share features of their internal IRs or even front-end languages, so any new DSL would simply cherry-pick features from a number of existing DSLs and wrap them into a simple front-end. This degree of composability is simply impossible with the function-based interpreted eDSLs.
A can recommend taking a look at the Nanopass [1] framework, which is built around this very ideology, or at my own DSL construction framework [2].
[1] http://andykeep.com/pubs/np-preprint.pdf
And some examples:
https://github.com/cisco/ChezScheme
https://github.com/eholk/harlan
[2] https://github.com/combinatorylogic/mbase
It will be interesting to see what the final winner of GPU programming looks like. There's also the possibility of FPGAs making their way into consumer hardware, and right now the pure-Python library MyHDL is a great choice for those. There are a few attempts at abstracting over OpenCL like https://github.com/eholk/harlan, and some intriguing domain specific attempts like http://halide-lang.org/ but I think it will be a while yet before something takes over. I also don't think whatever it is can succeed without corporate backing.
In PyPy 4.0.0 Released – A Jit with SIMD Vectorization and More> are even more niche
Exactly. Compilers construction is a very specific problem domain, which requires specially tailored DSLs, not a "general purpose" language. Haskell is a way too general purpose for this task.
> and no major programming language has been written in them.
C is even more unsuitable for this than Haskell, and yet most of the compilers are written in C. Technical superiority does not count at all in choosing an implementation platform.
> Because no known programming language resorts to "a few lines of Prolog" to save a few tens of lines for "region inference"?
JFYI, a prototype implementation of SSA for GCC was written in Prolog (see the Sebastian Pop works [1]). If embedding Prolog in C was technically feasible, it would have stayed this way. Also, to see how much Prolog rocks, check out Harlan [2]
In order to avoid u
Read the rest
nnecessary flame war: I give no crap to any popularity based arguments. Got any technical, well-grounded, rational arguments? Go on, I'd be delighted to comment. Otherwise I'm not interested. And, btw., you're clutching to just one out of four of my points against Haskell. Nothing to say about the other three?
[1] http://www.cri.ensmp.fr/classement/doc/A-381.pdf
[2] https://github.com/eholk/harlan
Currently Prolog-derived languages are making a sort of a comeback - Kanren is widely used, just look at the number of ports and variations. My favourite recent example of cKanren used inside a compiler is Harlan [1] (see the region inference pass).
P.S. I'm really getting tired of the ever growing proportion of video vs. text in the otherwise valuable content. I'm genuinely interested in the topic but there is no way I can watch it. Dreaming of a service which would transcribe arbitrary videos for a tiny fee.
[1] https://github.com/eholk/harlan
In Compilers Are Databases [video]Not even a full Prolog, but Datalog, is very well suited for querying about graphs. I.e., for quite a lot of things you want to do inside a compiler. See an example here: http://people.csail.mit.edu/mcarbin/papers/aplas05.pdf
I also use full Prolog to implement type systems.
Prolog extended with a constraint solver is another thing one may want to employ for an elaborate program analysis, see how https://github.com/eholk/harlan is using cKanren for its region inference.
So, in my book, Prolog per se may have very limited use outside of teaching, but an embedded Prolog or a dumbed down Datalog can be an extremely powerful querying DSL which can make LINQ look dumb and clumsy.
In Learn Prolog NowA very impressive use of cKanren is in Harlan ( https://github.com/eholk/harlan ) - it is doing the region inference there.
In MiniKanren – An embedded DSL for logic programmingThere's been a number of attempts to create hardware agonostic languages for GPGPU programming - examples are Brook (http://graphics.stanford.edu/projects/brookgpu/lang.html), and Harlan (https://github.com/eholk/harlan/wiki/Language-Overview), although there are many others. None seem to take off, as with most languages - and OpenCL seems like it's here to stay (perhaps because it requires little new learning on the part of C programmers, as it is just C with a few restrictions and a few additions). I think OpenCL will be the "assembly" of GPUs for a long time to come, and will generally be the primary target of higher level languages aiming to make use of the GPU.
In Proposal For An Interactive Introduction to Graphics ProgrammingThe project in question: https://github.com/eholk/harlan
In New Scheme-Based GPU Programming LanguageHarlan: a Language That Simplifies GPU Programming
1 points · Open discussionI really should update the user guide, since the language has changed a lot in the last year.
I have an earlier post that discusses a couple of the optimizations that Harlan does: http://blog.theincredibleholk.org/blog/2013/06/10/some-simpl...
To me the win for Harlan over CUDA is its region system, which lets you work with more intricate pointer structures in the GPU. For example, there is an interpreter for the Lambda Calculus as one of the test cases, which would be much harder to do in straight CUDA: https://github.com/eholk/harlan/blob/master/test/lambda3.kfc
Very soon, Harlan will have support for higher order procedures, which is also not available in CUDA.
In Harlan, new Lispy language for GPU programmingPretty cool, region inference is handled via miniKanren, a relational / constraint logic programming embedding in Scheme (also available in Clojure as core.logic):
http://github.com/eholk/harlan/blob/master/harlan/middle/inf...
In Harlan, new Lispy language for GPU programmingShowing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.