

LLVM 3.0 Type System Rewrite - bsiemon
http://blog.llvm.org/2011/11/llvm-30-type-system-rewrite.html

======
barrkel
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.

~~~
chipsy
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
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.

~~~
chipsy
Encapsulation is only somewhat more protective than simply adding a version
number on the file format. Not that it isn't helpful from a project-management
standpoint, but in the really complicated cases(real world example:
serializing the state of a video game down to the exact frame - many of the
entities want to reference each other, numerous static resource hooks, etc.),
there's an impedance at the moment you decide to serialize, and the design
challenge is mainly one of deciding where to attack it:

1\. By doing reflective magic (potentially a lot of it) at the moment of
serialization so that a serialization-friendly form can be teased out. If you
are not working within a reflective environment, this option doesn't exist
without additional effort. And if the runtime changes the magic breaks.

2\. By "primitivizing" the runtime so it's closer to the serialized
representation, at the expense of dirtying the codebase to exchange e.g.
object references for id numbers. You can make it look prettier again by
enforcing conventions, but the extra weight is still there. Adding reflection
within an environment that didn't have it built-in also requires going through
this step.

Those two options are the design tradeoff. And the bigger your serialization
ambitions go the more the pressure builds to either massively primitivize(e.g.
use a SQL database for all data and make the special runtime representations
non-persistent always) or make an image so that data never "actually" leaves
the runtime.

In electing to use a database layer everywhere, web apps have more-or-less
standardized on primitive designs, and subsequently try to claw back readable
code through tricks like ORMs and DSLs.

------
jmah
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.

