"All languages tend to directly or indirectly depend on C, so I try to cut out the middle men and program directly in C (unless I'm prototyping). "
No! No! No! You know Lisp but stopped at C!? You're missing an obvious possibility that someone like you could do interesting things with: a better language with C's data types, C's calling conventions, seemless use of C libraries, and ability to extract to C. And Scheme-like macros or just better templates (see Zig). As in, you get all the benefits of a better language and C's ecosystem at the same time without C's drawbacks. It's my default recommendation for language projects in system space given C's dominance and how mismatches cause performance penalties in many FFI's.
You certainly have the brains to do it. Who knows what you might come up with. Maybe start with Cyclone or Clay languages adding some features like Rust's borrow-checker or concurrency with DTHREADS. Maybe those Maybe's for error handling. Easier AST's so they can be manipulated by macros. Maybe a macro language with tree operators. Who knows. Only person I found doing it was ZL guy who impressively did C++, too:
Wait, someone told me Julia was originally syntactic sugar on top of a core of femotlisp. It's designed to effortlessly use C and Python libraries prevalent in its target area. Better programming experience than C with it faster than Python. So, add that, too.
If you're wondering, my motivation was for use in Brute-Force Assurance where I throw every tool I can at code to find problems. Most are written for C and Java. So, having a converter from a more ideal language to those to use their tooling is a necessity. Plus, C has a verified compiler to prevent compiler errors and/or Karger/Thompson attack. Scheme, esp Racket, is candidate for source language esp with ease of transformations. Htdp book might train new contributors. ZL models C and C++ but supposedly outputs C. Potentially something to use in it, too.
Now, I wonder what you would come up with extending C in a Lisp/Scheme mockup that outputs vanilla C. :)
> Maybe start with Cyclone or Clay languages adding some features like Rust's borrow-checker or concurrency with DTHREADS. Maybe those Maybe's for error handling. Easier AST's so they can be manipulated by macros. Maybe a macro language with tree operators. Who knows.
I'm kinda headed the other direction; I want to be able to start with existing projects and take features out. Similarly I'd like my projects to be easy for someone else to rip features out of.
You know all about my interest in bootstrapping, Nick :) The grand plan is to grow a high level language (Lisp to start with, but hackable by anyone to be anything) that bakes in implementation parsimony, dependency-injected syscalls, traces and layers from the ground up.
My SubX in SubX project is about half done. (OP was an extended detour for the last couple of weeks.) When it's done I'll be able to get off C completely. (Modulo using the C version for diverse double compilation.)
So yes, nobody wants to get off C more than me. There's a reason OP is phrased in the present tense.
Now, that's what I'm talking about! You just had worried there for a second! ;)
Your idea of taking stuff out is interesting. I'll note that using another language that outputs C might be desirable for improving automated analysis of a program, esp its meaning, for refactoring it into minimal or cleaner form. If not a different language, one sub-field you might want to look into is "feature-driven development" that tries, at programming or process level, to treat it like a product with features to include or not. I don't follow that given we already do that with repos. Might have something interesting for your language experiments, though.
Looking at it again, it's actually reusing stuff from Model-Driven Development with a feature focus. Ok, so FDD and MDD might both have useful concepts. There's also an open-source tool now. Interesting.
Anyway, your use case would be doing it in reverse with language and/or integrated build system tagging this stuff specifically to let you resynthesize a deployed application without unnecessary features. Don't take any of this too seriously, though, as I'm just brainstorming.
My `tangle` currently inserts `#line` directives, which helps with error messages. But inserting them into the git history is noisy. Another reason to create the repo from scratch on demand, using it only for browsing convenience, not as a source of truth.
it's great for small projects, and the reason we both discovered the same primitive it is because of it's extreme leverage: You get a lot (dependency resolution and incremental building) for almost nothing.
Unfortunately there doesn't seem to be any way to extend it to parallel builds.
Yeah. The best I could do was https://github.com/akkartik/mu/blob/master/build4, which I've shown you before. I find myself using it a lot, though it's good to know I have the non-parallel version as a fallback for the reasons mentioned at the top.