jank is C++
59 points by jeaye
59 points by jeaye
This is amazing progress. I really love just how nicely written this is
I really appreciate that someone is taking a Lisp written in Java and making it work with C++. It’s just the most bonkers ecosystem ever.
(cpp/type “std::map<std::string, int>”)
Why not (cpp/type (std::map (std::string int))) ?
std::map is not a valid Clojure symbol or keyword. That would require custom lexing support. This is why we use cpp/std.cout, for example.
Following that line of logic, one could try to encode this in Clojure data, for sure. But then I need to turn it back into a string in order to give it to Clang to parse anyway. I can see the data-driven argument for making types easier to build in macros, for example, but I’m going to need to design my own DSL for this and C++’s type system is not really something I want to build a DSL around. For example, this is a valid C++ type.
const F<void (int, float)>& (T::*)(V<int>&&) const
See what I mean? :)
Not knowing that ‘jank’ is a language makes your “jank creator” hat really funny.
(Congrats, btw!)
I was more commenting on keeping it lispy than choice of std:: vs std/. Class templates are like functions that take types and return a type, and function templates are like functions that take types and return a function.
For example const F<void (int, float)>& becomes:
(ref (const (F (functype (int float void)))))
You get the advantage of lisp sexp notation making the order of what’s happening much clearer. I can understand wanting the string approach for being able to more easily copy and paste between jank and C++, but if I were writing macros I would want the sexp form too.
Reading it, I prefer the 1:1-mapping. I’m generally not a fan of language idiom/type conversion. It’s often incomplete, leads to edge cases and questionable gain on the other side, at most fulfilling some feeling of purity or seamlessness that the a multi-language codebase never has in practice.