LLVM 3.0 Type System Rewrite

http://blog.llvm.org/2011/11/llvm-30-type-system-rewrite.html

by bmcniel • 15 years ago

121 5 15 years ago

blog.llvm.org

barrkel• 15 years ago

By a peculiar coincidence, this move to add names to what used to be structural types is almost exactly the opposite of something I want to do to Delphi (Object Pascal) for reverse reasons.

When you have run-time type information (RTTI) in a language it turns out that having names for types is important, for data serialization in particular. But when you also have anonymous types (as Delphi does), you can end up with versioning problems, because you need to generate names for these things - and they usually end up involving numbers of some kind.

So you can see a type that looks like this:

    type
      R = record
        X: record
          E: set of (a, b);
        end;
      end;

Only R has a name; the names of the types of the field R.X, and the field R.X.E, etc. are anonymous and end up being something like ':1', ':2' etc. But change the order of declarations and you change the numbering. So probably the most robust option is a name generated from the structure of the type, a bit like a mangled C++ signature.

chipsy2• 15 years ago

Serialization has a very interesting influence on types; when variables are disposable you can use very expressive types and complex relationships without major consequences.

But when it comes time to serialize, the effort to map all the properties and relationships into an enumerated form can very quickly invade the codebase and dominate it like a lodestone. Either you "bash down" the most structured elements into more primitive forms so that version compatibility is maintained(leading you to code in a primitive style as well), or you escalate to the prospect of storing code as well as data(the "image" strategy).

eschaton• 15 years ago

It doesn't require you to code in a primitive style, however: It just requires acknowledging that creating a storage format is just as much an act of design as creating any other interface.

For example, "transparent" serialization really isn't because you get run into severe versioning issues. But dropping to primitives doesn't work well either, because then there's impedance to deal with. If you acknowledge there is bound to be impedance, you can encapsulate it in a separate mapping/specification, and deal with it on its own terms.

That lets you do things like evolve your storage format and internal model independently, without the very real drawbacks of an image-style system.

jmah• 15 years ago

It's great to be able to get peeks into the development of a compiler toolchain. I'm always wary if I can't dispel magic, where "magic" means guardedly opaque. Corollary: Answers to questions about magic are typically, "you don't want to know." At least, that's the mood I've found surrounding GCC.

LLVM 3.0 Type System Rewrite

Related Stories