Our great sponsors
-
ferret
Ferret is a free software lisp implementation for real time embedded control systems. (by nakkaya)
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
fyi there's some middle ground via ferret if you want to mix the two in the future. I think janet lang is more full featured, borrowing ideas from clojure while targeting simple embedding alongside c.
fyi there's some middle ground via ferret if you want to mix the two in the future. I think janet lang is more full featured, borrowing ideas from clojure while targeting simple embedding alongside c.
If I do implement it, the most likely route I'd take is make a compiler in Clojure/clojurescript that uses Instaparse (I have a more-or-less-clojure grammar written that I was tinkering with) and generate C++ code that uses Immer for its data structures and Zug for transducers and what my not-quite-clojure would support would be heavily dependent on what the C++ code and libraries I use can do. I'd use Taskflow to implement a core.async style system (not sure how to implement channels, maybe this but I'm unsure if its a good fit, but I also haven't looked). I would ultimately want to be able to interact with C++ code, so having some way to call C++ classes (even templated ones) would be a must. I'm unsure if I would just copy (and extend as needed) Clojure's host interop functionality or not. I had toyed with the idea that you can define the native types (including templates) as part of the type annotations and then the user-level code basically just looks like a normal function. But I didn't take it very far yet, haven't had the time. The reason I'd take this approach is that I'm writing a good bit of C++ again and I'd love to do that in this not-quite-clojure language, if I did make it. A bunch of languages, like Haxe and Nim compile to C or C++, so I think its a perfectly reasonable approach, and if interop works well enough, then just like Clojure was able to leverage the Java ecosystem, not-quite-clojure could be bootstrapped by leveraging the C++ ecosystem. But its mostly just a vague dream right now.
If I do implement it, the most likely route I'd take is make a compiler in Clojure/clojurescript that uses Instaparse (I have a more-or-less-clojure grammar written that I was tinkering with) and generate C++ code that uses Immer for its data structures and Zug for transducers and what my not-quite-clojure would support would be heavily dependent on what the C++ code and libraries I use can do. I'd use Taskflow to implement a core.async style system (not sure how to implement channels, maybe this but I'm unsure if its a good fit, but I also haven't looked). I would ultimately want to be able to interact with C++ code, so having some way to call C++ classes (even templated ones) would be a must. I'm unsure if I would just copy (and extend as needed) Clojure's host interop functionality or not. I had toyed with the idea that you can define the native types (including templates) as part of the type annotations and then the user-level code basically just looks like a normal function. But I didn't take it very far yet, haven't had the time. The reason I'd take this approach is that I'm writing a good bit of C++ again and I'd love to do that in this not-quite-clojure language, if I did make it. A bunch of languages, like Haxe and Nim compile to C or C++, so I think its a perfectly reasonable approach, and if interop works well enough, then just like Clojure was able to leverage the Java ecosystem, not-quite-clojure could be bootstrapped by leveraging the C++ ecosystem. But its mostly just a vague dream right now.
Thanks for taking the time to provide a detailed response. Need to think on this. I had actually started a regular Clojure parser using LLVM as a hobby, but then my friend said it was better to implement this in a safe-memory and. save-concurrency language like Rust and leverage cranelift for code generation. So, now I am learning rust, lol. (Btw, Rust has a persistent data structures lib too: https://github.com/orium/rpds )
Thanks for taking the time to provide a detailed response. Need to think on this. I had actually started a regular Clojure parser using LLVM as a hobby, but then my friend said it was better to implement this in a safe-memory and. save-concurrency language like Rust and leverage cranelift for code generation. So, now I am learning rust, lol. (Btw, Rust has a persistent data structures lib too: https://github.com/orium/rpds )
Ideally, there would be multiple options: C++ for production builds, maybe an interpreter for development, so you only have to pay for the compile time cost when you're doing a release build. But of course, that duplicates the implementation effort needed. My main reason for wanting to use C++ over C (or anything else) is that, as I said, I write a bunch of C++ and if I were making my ideal language, I would of course want to use it as a replacement there and a big part of why I use C++ over a "better" language like Rust (besides the big one: that I already know C++) is access to the libraries I want to use, for example, for my hobby game development, I want to use the excellent EnTT library and I don't want to give that up. That means my language needs to provide a way to continue to use those libraries, which means interop with C++ and the ability to declare and use templated classes and functions (something I wouldn't easily be able to do if I compile to C).
I do like this approach and had considered Rust and Ocaml as an implementation language (and Rust using pest is still something I'd consider, maybe not for version 1, but maybe later so that the compiler can be a small fast-startup binary) and I do like the idea of using wasm or LLVM for the runtime, but ultimately source-level C++ interop (so I can use header-only template heavy libraries) was too important to me personally. Like I said, the language would be very heavily designed and built for my own use cases, since.. well, why else would I make a language, especially since there are so many languages and very few gain any meaningful traction.