Next step Go-lisp!
Way ahead of you.
Although this library will be useful for adding better data structures to the language. I was thinking of adding immutable dictionaries and sets. This will save me from having to implement them myself.
Glad someone may find it useful :) Let me know if there’s anything missing from it that you feel you’d like to have. I don’t want to clutter the primary package up too much, but I wouldn’t be adverse to having a seq-extra sub-package with community requested functionality.
I’m beginning my trek into making a Clojurescript game about time travel. I’m loosely following Chris Granger’s Conj talk about Component Entity System.
I got lost when he showed his 21 pass sample compiler.
It’s not clear how he figured out what the passes should be, nor what order was best.
I don’t think he was trying to focus on which specific steps to do in which order, but more the whole idea of using little tiny (nano) passes to do compilation.
That said, I sure would like more details. I spent most of the day trying to find more lectures/books/courses on using scheme for building compilers. I’ve played around a little with trying to build toy language compilers in clojure (actually more like clojure data-structure compilers) using LLVM, but that’s not the same thing. I’d like to learn more about the types of optimizations he was talking about and how to use that toolkit.
I’ve only found a few good resources so far and no lectures:
I don’t think he was trying to focus on which specific steps to do in which order
I don’t either. But it seems (to me) to be a difficult area with this idea. Sure, if you can figure out a bunch of nano-passes, that probably is a good design. But what process do you use to identify each pass?
Good list of links.
I think each pass represented a small change in code, like adding a return statement to make it look more like C (i.e. (return foo) ). Then each pass would grow organically from what he needs, hence the order.
As to what exactly each pass should contain, that would be more specific to the compiler/optimizations you’d be building.
As an interesting aside, numbers that are used as the initial state of a crypto function are called nothing up my sleeve numbers.
They’re supposed to be “nothing up your sleeve” numbers. The problem
is, the numbers used in Dual_EC_RBG aren’t – it was never explained
where they came from. A cryptographic function should explain how the
numbers were chosen in order for them to be proper “nothing up your