Pruebas dinámicas de los moldes abajo como se explica en TAPL

Question

En la página 195 del libro de TAPL Pierce, afirma que uno puede reemplazar un operador de fundición a fondo por algún tipo de prueba de tipo dinámico. Luego da las siguientes reglas:

t-tipetest:

$ \ dfrac {\ gamma \ vdash t_1: s \; \; \ Gamma, X: T \ Vdash T_2: U \; \; \ Gamma \ vdash t_3: u} {\ gamma \ vdash \ texto {if} t_1 \ texto {en} t \ texto {luego} x \ a t_2 \ texto {else} t_3 \ a t_3: u} $

e-e-tipetest1:

$ \ dfrac {\ vdash v_1: t} {\ texto {if} v_1 \ texto {en} t \ texto {luego} x \ a t_2 \ texto {else} T_3 \ a [x \ mapsto v_1] t_2} $

e-tipetest2:

$ \ dfrac {\ nvdash v_1: t} {\ texto {if} v_1 \ texto {en} t \ texto {luego} x \ a t_2 \ texto {else} T_3 \ a T_3} $

No hay ninguna explicación más y desconoce cómo interpretar estas reglas. Revisándolos, me doy cuenta de que la primera es una regla de escritura y la segunda y tercera son las reglas de evaluación. Sin embargo, la sintaxis es un poco extraña. ¿Cuáles son las flechas en cada rama del IF? ¿Por qué el IF incluye el insynex?

Answer 1

La primera regla T-Typetest es una regla de cheques de tipo. Vamos a leerlo juntos. En primer lugar, $ \ gamma $ no es importante (en una primera lectura al menos). Tenemos las siguientes premisas:

1. $ t_1 $ tiene tipo $ s $
2. si $ x $ tiene tipo $ t $ luego $ T_2 $ tiene tipo $ u $
3. $ t_3 $ tiene tipo $ u $

Las conclusiones son, que obtenemos una expresión de tipo $ u $ (creo que su transcripción debe tener " $ : U $ "en lugar de $ \ a t_3 $ la conclusión): $$ \ mathrm {if} \; t_1 \; \ mathrm {in} \; T \; \ MATHRM {LUEGO} \; x \ a t_2 \; \ mathrm {else} \; T_3 \ TAG {1} $$ El significado de esta expresión puede ser desbordado al observar las otras dos reglas, que son semánticas operativas de pequeño paso. Aquí hay una explicación incorrecta, que haremos correcta en un momento:

1. Si $ t_1 $ tiene tipo $ t $ luego (1) evalúa a < Span Class="Math-contenedor"> $ T_2 $ con $ x $ reemplazado por $ t_1 $ < / span>. Este es el caso de "Downcast", es decir, $ t_1 $ está inactivo desde $ s $ a < Span Class="Math-contenedor"> $ t $ , el valor de Downcast está unido a $ x $ y luego $ t_2 $ se ejecuta.

2. Si $ t_2 $ no tiene tipo $ t $ luego (1) evalúa a $ t_3 $ . Este es el "predeterminado" que usamos cuando el desconexión no es posible.

La explicación anterior es incorrecta porque deberíamos usar $ v_1 $ en lugar de $ t_1 $ , por que el autor le está diciendo: Primero evalúe $ t_1 $ a $ v_1 $ y luego realice el descenso .

En un idioma imaginario OO lo mismo podría escribirse algo así:

S t1 = ...;
...
if (t1 instanceof T) {
  T x = (T)t1;
  t2;
} else {
  t3;
}