harlan
harlan copied to clipboard
eholk
A language for GPU computing.
Many GPU algorithms are formulated with lots of mutation, and Harlan doesn't handle these with the greatest performance. We should consider some restricted forms of mutation. Some of them may...
Named fields would let them work more like structs. Alternatively, we could just add structs or records as a separate entity from ADTs.
We avoided these originally because we wanted Harlan to feel like a dynamically-typed language--that is, the programmer would never have to see or write a type annotation. We've strayed away...
Unary ADTs is a pretty common pattern in Harlan as a way of getting structs and tuples. For these cases, it'd be nice to be able to destructure them in...
For a lot of array programming, a rectangular shape is perfectly fine and has some nice efficiency advantages over a vector-of-vectors representation. It'd be nice to be able to work...
Currently to do a matrix sum you have to do something like this: ``` (reduce + (kernel ((row matrix)) (reduce + row))) ``` Having to do two reduces and a...
It'd be nice to be able to have local definitions, such as `define` and `define-datatype`. We have most of the machinery needed already, it's basically just a matter of finding...
A program like this one doesn't pass type inference: ``` (module (define (main) (foo 5))) (define (foo x) (println 5))) ``` The type inferencer tries to type `foo` in isolation,...
With type inference, it's sometimes surprising what types we end up with. We should add a tool that infers the types and then dumps out the types that Harlan found....
The `remove-nested-kernels` pass can't follow these nesting paths, and should. This is especially important as we rely more on libraries.