Part zero made me chuckle! Whenever I start a project I go through the same motion of trying to find a good name for it. I am sure it is not rational, but somehow I would hate the project myself if the name doesn’t feel right.
I decided to pick a naming theme and name every new experiment folder accordingly. Works pretty well, surprisingly as/if your project evolves you tend to find connections with the (randomly picked) name.
Def fun for personal projects, but when it comes to work, I've been on projects made up of multiple services with the silliest, vaguest names ever; all this did was made it impossible to remember what each service actually did! Such a hassle.
If I can’t immediately decide on a good name, I like to take a single word (or occasionally as many as three) that describes it, and take the initial (or initials) and use that as a code name. That way I know I’ve got to change it, and avoid the risk of retaining a bad name because of inertia. One project I have going at present is code named “B”. Some previous examples have been “ABC”, “C” and “V”.
If your langauge is functional (has closures), I would recommend checking out[0] which is a full end-to-end tutorial on compiling a functional language to C and could be adapted to LLVM, using Haskell as the implementation language.
Basically the only slightly non-trivial step is closure conversion[1] which lifts free (AKA "captured" in C++ terminology) variables from a closure, which lets you encode closures faithfully in a first-order language with structs.
If you translate your language to use Continuation Passing Style [0], then you get tail-calls for every function, which effectively obviates the stack.
This technique is used by functional language compilers, see Compiling With Continuations for more info on the underlying theory
> then you get tail-calls for every function, which effectively obviates the stack.
This is true, however CPS moves the work from the stack to the heap, so a deep enough recursion would exhaust the heap instead. Using a trampoline[0] in conjunction with CPS ensure constant stack usage for tail-recursive functions.
That is a good question. Although tail-call is easy to describe and understand I've haven't implemented it myself. I'd also appreciate pointers to resources.
Code generation is pretty hard. I'd start by generating arithmetic from your AST. Then focus on getting a simple function to compile. Don't worry if this requires a lot of hard coding. Once you get to the harder concepts like closures, consider making a secondary IR that simplifies code gen. I have a typed AST representation that desugars various concepts like first class functions, destructuring, etc.
I'm actually compiling to WebAssembly but it's the same principles
I also want to generate webassembly. I compared the option of generating wasm directly with using llvm. The wasm spec is hard to read without enough examples.
My current approach is writing my runtime in c or c++, and put most logic there. And I will try to generate c code first, and compile the c code using clang and learn from the generated IR.
I kinda want to write the runtime also in rust, but I don't know if linking will be a problem.
Generating C seems like a good middle ground. I also considered that. Frankly though code generation is hard regardless because you’re gonna have some abstractions that just don’t lower nicely.
Writing the runtime in Rust might work but ownership might get in the way.
Happy to talk about this more if you want. Shoot me an email
I find font-family stacks to regularly be a source of amusement and/or bafflement. Here’s this site’s main one:
font-family: freight-text, Iowan Old Style, Georgia, system-ui, -apple-system, Segoe UI, Roboto, Ubuntu, Cantarell, Noto Sans, sans-serif;
I… what? The web-font serif, then a macOS (I think?) serif, then a Windows serif, then… system-ui stuff which is almost always sans-serif, then sans-serif fallbacks. This is a bizarre mixture.
This immediately makes much more sense:
font-family: freight-text, Iowan Old Style, Georgia, serif;
And I tend to think just this would be better:
font-family: freight-text, serif;
Also, one other rule that I can’t let pass by without comment:
letter-spacing: .01em;
Bumping letter-spacing is always risky: the designer chose the spacing they did for a reason. Pretty much the only circumstances you should do it are (a) very specific display purposes (that is, headings and the likes—typically 0.2em or more) and (b) all caps (typically something like 0.07ex). Body text letter-spacing bumps are almost always a bad idea. In this case, it’s even already using a fairly wide font. (Well, so long as freight-text is used. I really wish all font properties (font-, letter-spacing, &c.*) could be varied by font availability, so that you could do things like bump font-size if you use your own web font with smaller metrics than the likely fallback font.)
It might make sense to stretch the code blocks, to avoid horizontal scrolling which is quite annoying when reading code. Similar to photos breaking out of the text column on various sites.
Also on the topic of horizontal scrolling, `overflow: scroll` is almost never what you want, because it causes scrollbars to be drawn even if unneeded. >99.99999% of the time you want `overflow: auto` which draws scrollbars only if needed.
