need some clarification on compile-time type vs. run-time type

[Yuh-Ruey Chen]

Yuh-Ruey Chen wrote:
> If the main problem is that value exprs and type exprs are incompatible,
> then why not make them compatible? Make it so that the only difference
> between the two is that type-expr-like value exprs evaluate to
> meta-objects and actual type exprs require fixed type properties. With
> these as the only two differences and with no exceptions, I hope it will
> be as intuitive as possible. The additional benefits is that type exprs
> can be used much more freely since they will be a subset of value exprs.
> Since the syntax of value exprs is fixed (due to compatibility
> constraints), the only way to do this is to adjust the syntax of type
> exprs. And this is where I'll violate the syntax brevity goal, which may
> not be such a bad thing since it the intent of the syntax is now more
> clear. Now to get into details:
>
> The only real non-syntactic issue between type exprs and value exprs is
> that in type exprs, the identifiers must be fixed type properties.
> Everything else, such structural types and function types (ignoring the
> identifiers), is fixed. For ex, |{p: x}| will always mean the same
> thing, given that x is a fixed type; it can't be mutated. The rest of
> the issues are syntactic ambiguities. So for each of these ambiguities
> that I'm aware of, I'll either prefix it with |type| or "match" the
> semantics between the value and type expr. Note that |type| is no longer
> an operator; it can only be used in certain situations as listed below
> (and as the type declaration/alias statement).

Also, the elimination of the separation between type exprs and value
exprs in favor of focusing on fixed type properties vs. non-fixed
properties should be vaguely familiar with C++ programmers. If you
consider fixed type properties in type exprs as a form of C++ "const",
then it's similar in that you have to make sure everything that
everything that is const, only contains const exprs, and ultimately
const identifiers. Actually, a more proper analogous example would be
C++ templates, which work on the equivalent of ES4 fixed types (and
const values). This fixed vs. non-fixed distinction is the only thing
users need to be aware of - otherwise, they can mix and match type and
value exprs freely. That's why I argue that this is easier to grasp (or
at least more familiar) than the current type expr vs. value expr
distinction.

-Yuh-Ruey Chen