First, I know there are some plans to clean up the error reporting format that sound interesting, so what follows may not be entirely relevant except in the short term, so feel free to ignore. However, documenting the internal types used in the ATS compiler could still be useful in the long term maintenance of the system, I would think.
I still think it is a bit hard for me to read the types though, not because the output is ugly (I don't think it is, anymore - maybe I got used to it), but just because I don't know what it all means - both the grammar of the types and the type parameters themselves.
For instance, here are two types:
S2Eapp(S2Ecst(g1int_int_t0ype); S2Ecst(int_kind), S2Eintinf(7))
S2Eapp(S2Ecst(g0int_t0ype); S2Ecst(int_kind))
My *guess* is as follows:
Clearly the first is a g1int and the second is a g0int, and they are composed of the c-type (S2Ecst --- I guess this may not mean exactly c-type) of int_kind. Additionally, a g1int requires some constraints, which is what the S2Eintinf is; "intinf" reflects that ATS2 by default uses GMP for infinite precision integer sorts.
So what is before the semicolon shows the name of the type, and what is after it shows its machine representation type, and constraints follow the comma (I probably need a bigger sample size with more complex examples).
I can't recall what S2Eapp (or S2Eexi, not shown in this example) is at the outer level for example.
I believe documenting these types is probably a high priority so I will start collecting what information I can. I've quickly put a few things here: