Richard Feldman

The long-term goal is definitely to have the compiler be a standalone binary, so I'm adding the `bug` label to this!

> It might be reasonable to generate generic versions of this file for each architecture and ingest them into the roc app, but that would bloat the roc app for...

Oh yeah, sorry - we are talking about the same thing! My wording wasn't ideal. 😅 > Since we have to ingest the llvm bytecode files anyway, is there an...

> How should functions associated with abilities be passed around? That is, dictionary passing, pure monomorphization, the trick Swift does, or something else? I always had monomorphization in mind for...

> What is the concrete set of built-in abilities Roc will support? How will those be derived for user-space types? The ones I'm confident we'll want: `Eq`, `Sort` (aka Ord),...

> Can abilities inherit other abilities? Kinda? An important relationship is that if I have something with the `Int` ability, that must imply that it has the `Num` ability. So...

> Abilities will need to have their own set of resolution rules. What will that resolver look like? Can we get away with path-walking and union-find-like optimizations like we do...

So like "if you have `Shaable` you automatically have `Eq` too, with this default implementation, but you can override it if you want?"

That seems like a plausible feature, but I doubt it's something where we'd get a ton of benefit for designing for it up front (as opposed to adding it later...

> As an aside, we should probably update the compiler to just not call `roc_alloc` when dealing with zero sized types. This is actually useful in the very specific use...