"FIXME" Doesn't Always Mean "Fix Me"

If you browse through the Swift (or LLVM) codebase for a while, you’ll see a comment like this:

// FIXME: Dependencies should be de-duplicated at serialization time,
// not now.

Many-to-Many Protocols

My colleague Michael Ilseman shared a design problem with me today, which came down to something like this:

Today, we have a protocol RawRepresentable, which says that “if I have a type X, I can convert it to and from X.RawValue”. You can then make a whole host of types that use Int as the raw value, and indeed that’s how Swift represents enums imported from Objective-C. (Well, those with an NSInteger underlying type, at least.) That makes this, in some sense, a “many-to-one” relation, because many types can have the same one raw value type. But what you can’t do is make a single type have multiple RawValue types—one of them has to claim the name X.RawValue.

The New Kingdom of Nouns

Last time I talked about how algebraic abstractions like “monoid” and “semigroup” didn’t seem to be pulling their weight, despite love from functional programmers. That focused on a practical issue: do these abstractions aid or harm comprehension? Do they make programming easier or harder? (Of course, there’s not a simple answer to this question.)

This time, though, I want to talk about something more exploratory: do we have the right tools to talk about these abstractions? This post is therefore going to be much longer and contain a lot more rambling.