inferencia de tipos de sesión · resumen—el c´alculo de tipos de sesi ´on tal como es...

Inferencia de Tipos de Sesion

Ernesto Copello

Facultad de IngenierıaUniversidad ORT Uruguay

Montevideo, [email protected]

Telefono: +598 29021505

Resumen—El calculo de Tipos de Sesion tal como es introdu-cido en [1] estructura los programas en terminos de procesos con-currentes que se comunican estableciendo dialogos. Estos dialogospueden ser descriptos en forma abstracta mediante secuencias detipos de mensajes, cada uno de los cuales describe el formato ydireccion del mensaje. El sistema resultante impone una disciplinaque garantiza la compatibilidad de los dialogos entre procesos deun programa bien tipado. El sistema es polimorfico a la Curry,pero ningun tratamiento formal de este aspecto ni algoritmocompleto de inferencia ha sido publicado aun. En este trabajopresentamos una version de un fragmento no trivial del calculo deTipos de Sesion extendido con esquemas de tipos, y un algoritmoque infiere el esquema de tipos principal (Principal Type Scheme)para cualquier programa tipable, junto con la prueba de solidez(soundness) y completitud del mismo. Asimismo presentamos unaformalizacion completa en la Teorıa Constructiva de Tipos delcalculo de Tipos de Sesion y del algoritmo de inferencia junto ala demostracion de su demostracion de solidez, utilizando paraesto el asistente de demostraciones Agda.

Palabras Clave—Tipos de Sesion, inferencia de tipos, meta-teorıa formal de lenguajes de programacion, concurrencia

I. INTRODUCCION

En sistemas distribuidos es comun que la comunicacionsincronica punto a punto por un canal entre dos procesosconsista en un dialogo estructurado descrito por cierto proto-colo, el cual especifica el formato, direccion y secuenciacionde los mensajes. En [1] se introdujeron los Tipos de Sesion(Session Types), con el fin de controlar estaticamente que lacomunicacion siga un protocolo preestablecido. Los Tipos deSesion imponen una disciplina que garantiza la compatibilidaden los patrones de interaccion entre los procesos de un progra-ma bien tipado. Los errores capturados por este sistema vandesde desacuerdos en el formato o tipo de un mensaje entre elemisor y el receptor, interferencia de procesos externos en lacomunicacion punto a punto entre dos procesos, colisiones demensajes (ambas puntas envıan informacion al mismo tiemposobre un mismo canal), hasta algunos tipos de deadlockscuando ambos procesos quedan esperando simultaneamentepor informacion sobre un mismo canal.

I-A. Tipos de Sesion

Introducimos los Tipos de Sesion mediante un ejemploclasico de la literatura [2], [3]. Definimos a continuacion elprotocolo que describe una interaccion simplificada entre unusuario y un cajero automatico. Denotamos mediante letrascursivas a los datos que viajan, mientras que utilizamos

negrita para las opciones y procesos, utilizando la primer letraen mayuscula en estos ultimos.

1. El Cliente comunica su id al cajero, donde el id esun numero natural.

2. El Cajero contesta si se tiene fallo o exito.3. Si la respuesta es fallo entonces la interaccion termi-

na. Pero si en cambio es exito el Cliente respondecon una de las siguientes dos secuencias de interac-ciones:

a) El Cliente inicia un deposito.b) El Cliente comunica la cantidad a ser depo-

sitada, donde cantidad es un numero natural.c) El Cajero devuelve el saldo, donde saldo es

un numero natural.

O, alternativamente:

a) El Cliente inicia un retiro.b) El Cliente comunica la cantidad a ser reti-

rada.c) Dependiendo de si el saldo actual es mayor o

no a la cantidad deseada, el Cajero respondecon alguna de las siguientes interacciones:

El Cajero dispensa la cantidad pedida.

O, alternativamente:

El Cajero informa un sobregiro.

Las siguientes imagenes resumen los escenarios posiblesen el protocolo descrito anteriormente:

Cliente Cajero

id

fallo

Cliente Cajero

id

exito

deposito

cantidad

saldo

Cliente Cajero

id

exito

retiro

cantidad

dispensa

Cliente Cajero

id

exito

retiro

cantidad

sobregiro

Desde el punto de vista del Cliente el protocolo puededescribirse de la siguiente manera:

![nat];&{fallo : end, exito : ⊕{deposito : ![nat]; ?[nat]; end

, retiro : ![nat]; &{dispensa : end, sobregiro : end}}}

(1)

Se utilizan los operadores ! y ? para indicar el envıo yrecepcion de informacion de cierto tipo respectivamente. Losoperadores & y ⊕ indican la posibilidad de aceptar o selec-cionar una opcion respectivamente. Ası, mediante la expresion![nat], el protocolo comienza describiendo que el Clienteenvıa un natural. Luego con el operador & se especifica queespera una de las opciones: fallo o exito. En caso que laopcion recibida sea fallo, mediante el tipo end se especificaque no es posible ya comunicacion alguna. En caso que laopcion recibida sea exito, mediante ⊕ describe que puedeseleccionar arbitrariamente la opcion deposito o retiro. Encaso de decidir la opcion deposito se comporta de la siguienteforma: primero envıa un natural ![nat], luego espera un natural

?[nat], para finalmente dar por terminada la comunicacion,lo cual se representa mediante end. En caso que decida laopcion de retiro, manda un natural ![nat], y luego mediante &especifica que espera una de las siguientes opciones: dispensao sobregiro. En cualquiera de estos dos casos la comunicaciontermina.

Este mismo protocolo puede ahora ser visto desde el puntode vista del Cajero.

?[nat];⊕{fallo : end, exito : &{deposito : ?[nat]; ![nat]; end

, retiro : ?[nat];⊕{dispensa : end, sobregiro : end}}}

(2)

Observar al principio que cuando el Cliente envıa unnatural el Cajero debe ahora estar listo para recibirlo, lo cualse especifica mediante la expresion ?[nat]. Los operadores? y ! son duales o complementarios en este sentido ya quepara establecer una comunicacion entre dos procesos unodebe recibir y el otro enviar informacion del mismo tipo.Analogamente sucede con los operadores ⊕ y &: si un procesotiene la posibilidad de seleccionar entre varias opciones, espe-cificado mediante ⊕, el otro proceso debe ser capaz de aceptarcualquiera de ellas, lo cual es indicado con &, y viceversa.

Estas dos formas de describir este protocolo tanto desdeel punto de vista del Cliente como el dual correspondienteal Cajero, se corresponden con los Tipos de Sesion asociadosal canal de comunicacion entre estos dos agentes. El primerTipo de Sesion se corresponde con el extremo del canal delCliente, y el segundo se asocia al extremo opuesto del canal,correspondiente al Cajero.

La dualidad entre estos dos Tipos de Sesion se generalizadado lugar a la nocion de tipo dual o tipo complementario.Si llamamos α al tipo descrito en la definicion 1 entoncesdenotamos por α al tipo especificado en la definicion 2.Mas adelante en la seccion II-D presentamos la definicioninductiva del sistema de tipos, y definimos la funcion quedetermina el tipo complementario de un tipo de sesion dadocualquiera.

Mostramos ahora un posible proceso para un Cliente.

Cliente = accept a(x) in(x![id];x . {fallo : inact

, exito : if . . . thenx / deposito;x![cantidad];x?(saldo) in inact

elsex / retiro;x![cantidad];x . {dispensa : inact

, sobregiro : inact}})

(3)

En el proceso Cliente el nombre a designa un puerto comun, yla primitiva accept establece que el proceso acepta un dialogoo sesion el cual es designado con el nombre x. En realidad estavariable de canal x representa un extremo del canal, justamenteel correspondiente al Cliente.

Un posible proceso para un Cajero es el siguiente, dondela variable de canal y tiene el tipo de sesion α.

Cajero = request a(y) in(y?(id) in

(if . . . theny / fallo; inact

elsey / exito;y . {deposito : y?(cantidad) in

(. . . ;y![saldo];inact)

, retiro : y?(cantidad) in(if . . . then

y / dispensa;inact

elsey / sobregiro;inact)}))

(4)

La primitiva request es complementaria a accept y, entrelas dos acuerdan un canal de comunicacion sobre el nombrede puerto a. Los nombres de variables x e y representan cadaextremo de este canal de comunicacion creado mediante lasprimitivas anteriores. La operacion ! permite enviar informa-cion por un canal, mientras que la operacion ? se utiliza pararecibir informacion. Notar que esta sintaxis es la misma quela usada en los Tipos de Sesion. Para el envıo y recepcionde informacion (datos) hay variables de tipo nat como id,cantidad y saldo. Por otro lado, para seleccionar una opcionsobre un canal se utiliza el operador /, y para aceptar opcionespor un canal se utiliza .. La primitiva inact determina elfin del proceso. Se dispone tambien de saltos condicionales atraves de la primitiva if...then...else. En la literatura se losdenomina tambien ramas internas, dado que son bifurcacionesdebidas a condiciones internas del proceso, en contraposiciona la seleccion de opciones que brindan ramas externas, dondela seleccion de la rama que sera ejecutada depende de procesosexternos.

Presentamos la sintaxis completa del calculo de procesosen la seccion II-C. Esta sintaxis facilita la identificacion delas variables ligadas, que son todas aquellas que aparecendentro de parentesis curvos y luego seguidas de la palabrareservada in. Siguiendo esta idea vemos en los anterioresejemplos como los canales son ligados por los operadoresaccept y request, y las variables de datos aparecen ligadaspor el operador ?.

Finalmente, utilizando el operador | podemos ahora compo-ner el proceso Cliente y el proceso Cajero, para representarası el proceso en el cual estos dos procesos interactuan enparalelo:

Cliente | Cajero

Como vimos anteriormente los tipos de sesion de ambosprocesos son complementarios. Veremos en la seccion proximaque por esa razon esta composicion paralela estara bien tipadaen el sistema.

Notese que el lenguaje de procesos no tiene ninguna clasede anotaciones de tipado para las variables usadas. El sistema

de Tipos de Sesion que presentaremos es polimorfico a laCurry, esto es, existen procesos que admiten varias asigna-ciones de tipos bajo las reglas de tipado que presentaremosen la seccion II-D mas adelante. Por ejemplo, en el procesox?(y) in (x![y].end) la variable y puede tener cualquier tipo.Esto motiva la introduccion de variables de tipo que permitanmodelar estos tipos polimorficos, pasando ası a tener esquemasde tipos en vez de tipos. El algoritmo que infiere los tipos paraun proceso debe en realidad hallar el esquema de tipos “masgeneral” que tipe un proceso dado, esto es, el esquema de tiposprincipal (Principal Type Scheme) para cualquier programatipable.

I-B. Teorıa Constructiva de Tipos

En este trabajo utilizamos la Teorıa Constructiva de Tipospara realizar una formalizacion de los Tipos de Sesion. LaTeorıa Constructiva de Tipos es un sistema fundacional para lamatematica constructiva desarrollada por el logico sueco PerMartin-Lof. Siguiendo el isomorfismo de Curry-Howard [4],un teorema es representado mediante un tipo de datos y unaprueba de este teorema es un objeto de ese tipo. Ası, unaprueba de un teorema es en general una funcion que, dadaspruebas de las hipotesis, computa una prueba de la tesisdel teorema. Este sistema puede tambien ser usado como unlenguaje de programacion, donde las especificaciones son re-presentadas como tipos de datos y los programas como objetosde esos tipos. Gracias a que el control de tipos es decidibletenemos una forma automatica de chequear la correccion delas demostraciones y de los programas. Aprovechamos estacaracterıstica para desarrollar un algoritmo de inferencia deTipos de Sesion, para luego, utilizando el poder expresivo dela Teorıa Constructiva de Tipos, razonar acerca de propiedadesde este algoritmo. Esta ventaja de la Teorıa Constructiva deTipos sobre otros lenguajes estandares de programacion ha sidoobjeto de diversos estudios [5], [6].

Para codificar nuestro trabajo elegimos Agda [7], [8], [9].Este es un lenguaje de programacion con tipos funcionalesdependientes, y un asistente de pruebas a su vez, basado enla Teorıa Constructiva de Tipos descrita anteriormente. Tienefamilias inductivas, esto es, tipos de datos que dependen devalores. Posee tambien modulos parametrizables. Este lenguajetiene similitudes con otros asistentes de pruebas basados entipos dependientes, como Alf, Coq, Epigram, Matita y NuPRL.

I-C. Trabajos Relacionados

Los Tipos de Sesion aparecen en [1], mientras que lainferencia de Tipos de Sesion empieza a ser estudiada a partirde 2004 [10], y sigue siendo objeto de estudio en la actuali-dad [11], [12], [13], [14], [15]. A continuacion discutimos losprincipales trabajos relacionados con el nuestro en esta area.

En [13] se hace un estudio de una forma simplificada deTipos de Sesion, en un calculo de procesos sintacticamenterestringido que no brinda al programador la libertad de utilizardirectamente los canales de sesion. En todo momento sepueden utilizar solo dos canales simultaneamente. El primeroes llamado canal actual sobre el que se pueden utilizarlas primitivas usuales de envıo y recepcion de datos y deaceptacion y seleccion de opciones, mientras que el otro canalsirve solo para enviar informacion a un proceso llamado padre.

Como consecuencia de no tener libertad en el uso de canales,tampoco se permite enviar y recibir canales, perdiendose ası lafuncionalidad de delegacion que ejemplificaremos en la sec-cion II-B. El calculo presentado tiene primitivas de aceptaciony seleccion de opciones, y se propone una forma original deinferencia de tipos que permite que procesos que seleccionanmenos opciones tipen correctamente con procesos que ofrecenmas opciones. En ese trabajo se simplifica el sistema de tiposquitandose los tipos recursivos. Se demuestran la propiedadde type safety del calculo de procesos propuesto, y tambienla terminacion de uno de los sub algoritmos utilizados enla inferencia de tipos. Finalmente, se muestra la factibilidaddel algoritmo propuesto mencionando su implementacion enOCaml.

En [15] se estudian formas de inferir Tipos de Sesionmediante tecnicas de analisis de codigo a partir de programasimperativos, los cuales consisten en una secuencia de accionesde comunicacion.

Finalmente, los demas trabajos relacionados consisten prin-cipalmente en embeber determinados calculos de procesos consu respectivo sistema de tipos en lenguajes de programacionya existentes. En [10] se implementan Tipos de Sesion conun unico canal en Haskell, prohibiendo ası el uso explıcito delos canales. En ese trabajo se prueba la solidez del sistemaembebido. Tambien en [12] se implementan Tipos de Sesionen Haskell, pero agregando la posibilidad de usar multiplescanales de sesion. En contrapartida no demuestran ningunapropiedad de solidez del trabajo realizado. En esos dos trabajosse aprovecha el poderoso sistema de tipos polimorfico deHaskell, en particular se utilizan las clases de tipos condependencias funcionales [16] para modelar ası la progresionen el uso de los canales, ganando de esta forma la inferencia enlos Tipos de Sesion embebidos a traves del sistema de tipos delpropio lenguaje anfitrion. En [11] se muestra una tecnica unpoco mas general para codificar los Tipos de Sesion, ganandomayor portabilidad en el lenguaje anfitrion. De esta forma sepuede codificar en otros lenguajes ademas de Haskell, comoML y Java. En particular se establece que la tecnica es portablea cualquier lenguaje que posea un sistema de tipos polimorfico.Este trabajo permite la comunicacion en multiples canales,pero solamente demuestra la solidez del trabajo para el casode un unico canal.

I-D. Objetivos Principales y Descripcion del Desarrollo delTrabajo

Existen varias presentaciones de los Tipos de Sesion [19],[20], [21], [22], [1], [3], [2], [23], [24], [25]. En varias de ellasha habido antecedentes de propiedades erroneamente atribuidasal sistema, con lo cual la formalizacion de la teorıa se haceinteresante desde el punto de vista de la confiabilidad de losresultados. El principal objetivo de este trabajo es realizarun experimento inicial con Tipos de Sesion, haciendo uso dela Teorıa Constructiva de Tipos como sistema logico de laformalizacion. Queremos ver propiedades del sistema de Tiposde Sesion mediante una rigurosa formalizacion de este sistemade forma de verificar su validez; y en particular, mostraremoscomo esta formalizacion puede ser utilizada para elaborarun algoritmo de inferencia de Tipos de Sesion y demostrarsu correccion. Por el momento no conocemos trabajos queformulen algoritmos completos de inferencia de Tipos de

Sesion ni mucho menos que formalicen su correccion en unasistente de pruebas.

A continuacion describimos la estructura de este trabajo.En la proxima seccion comenzamos definiendo formalmentelos Tipos de Sesion. En la seccion III presentamos un algoritmode inferencia solido y completo para un fragmento significa-tivo del calculo de Tipos de Sesion. Asimismo presentamoslos principales resultados de la demostracion de solidez delalgoritmo presentado. No desarrollamos en este resumen lasdemostraciones, aunque sı enunciamos los principales resul-tados. Las demostraciones completas pueden leerse en [17].En la seccion IV describimos brevemente la formalizacionhecha en la Teorıa Constructiva de Tipos utilizando el asistentede demostraciones Agda, y los problemas encontrados. Undesarrollo mas completo puede ser vistos en detalle en laversion completa de esta tesis [18]. Finalmente presentamoslas conclusiones de este trabajo y posibles trabajos a futuro enla seccion V.

II. TIPOS DE SESION

En las siguientes secciones retomamos el ejemplo presen-tado en la introduccion para introducir el sistema de tipos, ylas reglas basicas de tipado de los Tipos de Sesion.

II-A. Reglas basicas del Sistema de Tipos de Sesion

En el ejemplo dado en la seccion I-A introdujimos loselementos basicos del calculo de Tipos de Sesion. En estaseccion daremos las reglas del sistema de tipos para estoselementos. En este calculo de procesos existen distintos tiposde nombres o variables: de datos (tipos basicos), de canalesde sesion, de puertos y finalmente de procesos.

Mediante el sistema de reglas de asignacion de tipos, elsistema de Tipos de Sesion asigna tipos basicos S a lasvariables de tipos de datos, tipos de sesion o de canales αa los canales de sesion, tipos de la forma 〈α, α〉 a los puertosde un proceso P , y tipos de la forma Sα a las variables deprocesos. Los juicios de tipado son de la forma:

Θ; Γ ` P .∆

Este juicio se lee: si los puertos y las variables de datosusados en P tienen los tipos especificados en Γ y las variablesde procesos usados en P tienen los tipos dados en Θ, entonceslos canales usados en P se comportan de acuerdo a los tiposespecificados en ∆.

La expresion ∆ · x:α denota la extension del contexto ∆con la asignacion del tipo α a la variable x. Esta expresionexige que x 6∈ dom(∆), esto es, que x no este declarada en ∆.Esta notacion se extiende tambien a los contextos de procesos,y de puertos y variables.

Las reglas de tipado para la inicializacion de sesiones,llamadas [ACC] y [REQ], establecen que las variables decanales x ligadas por las primitivas accept y request sobreun puerto comun a, tengan respectivamente los tipos de sesionα y α especificados por el tipo de este puerto en el contextoΓ.

Γ ` a . 〈α, α〉 Θ; Γ ` P .∆ · x:α[ACC]

Θ; Γ ` accept a(x) in P .∆

Γ ` a . 〈α, α〉 Θ; Γ ` P .∆ · x:α[REQ]

Θ; Γ ` request a(x) in P .∆

Para ilustrar el uso de estas reglas, volvemos al ejemplo dela seccion I-A. Si abreviamos mediante α al Tipo de Sesiondefinido en 1, llamamos SubCliente al proceso resultantede quitar la primitiva accept del proceso Cliente definidoen 3, y llamamos SubCajero al proceso resultante de quitar laprimitiva request del proceso Cajero presentado en 4, por loexplicado informalmente hasta ahora tenemos que se satisfacenlos siguientes juicios:

∅; {a:〈α, α〉} ` SubCliente . {x:α}

∅; {a:〈α, α〉} ` SubCajero . {y:α}

Aplicando las reglas [ACC] y [REQ] a partir de estos juiciosse puede verificar que el puerto a tiene el tipo 〈α, α〉 en losprocesos Cliente y Cajero.

{a:〈α, α〉} ` a .〈α, α〉 ∅; {a:〈α, α〉} ` SubCliente.{x:α}[ACC]

∅; {a:〈α, α〉} ` accept a(x) in SubCliente︸︷︷︸Cliente

.∅

{a:〈α, α〉} ` a .〈α, α〉 ∅; {a:〈α, α〉} ` SubCajero.{y:α}[REQ]

∅; {a:〈α, α〉} ` request a(y) in SubCajero︸︷︷︸Cajero

.∅

Las reglas [SEND] y [RCV] sirven para ir formando losTipos de Sesion, tal como se observa en las siguientes reglas.

Γ ` e . S Θ; Γ ` P .∆ · k:α[SEND]

Θ; Γ ` k![e];P .∆ · k:![S];α

Θ; Γ · x:S ` P .∆ · k:α[RCV]

Θ; Γ ` k?(x) in P .∆ · k:?[S];α

Si en un proceso P el tipo α especifica el protocolo decomunicacion del canal k y el vector de tipos basicos Sespecifica los tipos del vector de expresiones e, entonces laregla [SEND] define que k tiene que tener el tipo ![S];α en elproceso k![e];P . La regla complementaria [RCV] es analoga,solo que, como el operador ? liga las variables que aparecenen el vector x dentro del proceso P , estas variables no tienenalcance fuera de este proceso. Debido a esto la regla [RCV]quita la informacion de tipo de las variables x del contextoque tipa el proceso k?(x) in P .

Por otra parte las reglas [BR] y [SEL] muestran como lostipos de sesion α son construidos a partir de la informacionbrindada por los operadores de seleccion de opciones. Si∀i ∈ 1, . . . , n el tipo de sesion αi especifica el protocolode comunicacion del canal de sesion k en el proceso Pi,entonces la regla [BR] establece que el tipo &{l1:α1 . . . ln:αn}determina el comportamiento del canal k en el procesok.{l1:P1 . . . ln:Pn}. La regla complementaria [SEL] determinaque si en un proceso P una variable de canal k se comporta

segun la especificacion dada por el tipo αj , entonces este canaltiene que tener un tipo ⊕{l1:α1, . . . , lj :αj , . . . , ln:αn}, dondejustamente se establece que la etiqueta lj tiene necesariamenteasociado el tipo αj , en el proceso k / lj ;P

Θ; Γ ` P1 .∆ · k:α1 . . . Θ; Γ ` Pn .∆ · k:αn [BR]Θ; Γ ` k . {l1:P1 . . . ln:Pn} .∆ · k:&{l1:α1 . . . ln:αn}

Θ; Γ ` P .∆ · k:αj(1 ≤ j ≤ n)[SEL]

Θ; Γ ` k / lj ;P .∆ · k:⊕ {l1:α1 . . . ln:αn}

La regla base para la construccion de los tipos de sesionesta dada por la regla [INACT], la cual determina que todoslos tipos de sesion que aparezcan en el contexto ∆ tienen quetener tipo end (que sera a su vez el caso base en la definicioninductiva de los tipos de sesion introducida en la seccion II-D).Intuitivamente, dado que el proceso inact representa el fin delproceso, no es entonces posible comunicacion alguna, y portanto los canales tienen que tener tipo end.

∆ solo contiente tipos end[INACT]

Θ; Γ ` inact .∆

Volviendo al ejemplo de la seccion anterior, para tipar elproceso Cliente|Cajero introducimos la regla [CONC]. Estadetermina que si un proceso P es tipable bajo los contextosΘ, Γ y ∆, y el proceso Q es tipable bajo los contextos Θ, Γ y∆′, entonces el proceso P | Q es tipable bajo los contextos Θ,Γ y ∆ ⊗∆′. Utilizar los mismos contextos Θ y Γ para tiparlos procesos que forman la composicion paralela garantiza elmismo uso para las variables de tipos basicos y los puertosdeclarados en ellos. La operacion ⊗ “une” la informacion dedos contextos de canal siempre que estos sean congruentes.Dos contextos son congruentes si, en el caso que ambos tipenun mismo canal, al menos uno de ellos le asocia el tipo end(no permitiendo comunicacion alguna). La idea del uso deloperador ⊗ en esta regla es no permitir interferencias en lacomunicacion punto a punto, esto es, que en todo momentosolo dos procesos puedan estar comunicandose a traves de unmismo canal. Si un mismo extremo de canal se utiliza en losprocesos P y Q, entonces su informacion de tipo va ser distintade end en ambos contextos ∆ y ∆′, con lo cual estos no serancongruentes.

Θ; Γ ` P .∆ Θ; Γ ` Q .∆′[CONC]

Θ; Γ ` P | Q .∆⊗∆′

Utilizando la regla [CONC] podemos terminar la asignacionde tipos para el ejemplo del proceso Cliente | Cajero.

∅; {a:〈α, α〉} ` Cliente . ∅ ∅; {a:〈α, α〉} ` Cajero . ∅[CONC]

∅; {a:〈α, α〉} ` Cliente | Cajero . ∅

II-B. Cajero Automatico con Delegacion

El poder real de los calculos de procesos como el calculoπ y otros calculos similares, proviene de la habilidad de enviary recibir canales, permitiendo ası la delegacion de canalesde comunicacion. Para introducir este concepto consideramosahora una version mas compleja del ejemplo ya presentado,

donde para completar el protocolo el Cajero delega las accio-nes sobre la cuenta del Cliente directamente a otro procesoque representa a un Banco.

En la imagen siguiente podemos ver el protocolo en unescenario de retiro exitoso de dinero, donde apreciamos queluego de la autenticacion exitosa, el Cajero envıa la iden-tificacion al Banco y posteriormente delega todo el trabajodirectamente al Banco sin que el Cliente pueda percibir estecambio. El escenario en el que la autenticacion falla es identicoal ya presentado en la seccion anterior, mientras que losescenarios de deposito y sobregiro son analogos al de retiroexitoso que presentamos a continuacion.

Cliente Cajero Banco

id

exito

id

retiro

cantidad

dispensa

Para representar esto se agrega una nueva sesion de comu-nicacion entre el Cajero y el Banco, sobre la cual inicialmenteel Cajero envıa el id del Cliente, para luego enviar su extremodel canal de comunicacion acordado antes con el Cliente. Lue-go de esto el Banco se comporta tal cual lo hacıa el Cajero enel ejemplo anterior. Ası el Cliente no tiene cambio alguno ensu comportamiento, por lo que tiene el mismo tipo de sesion,y el mismo proceso descritos anteriormente, compobandosetotal transparencia en como se produce la delegacion parael cliente. El tipo de sesion que especifica el protocolo decomunicacion del canal entre el Cliente y el Cajero visto enla definicion 2 no se altera, ya que simplemente agregamosotro canal de comunicacion entre el Cajero y Banco, sobreel cual delegamos parte del uso del canal acordado entre elCliente y el Cajero. En la definicion 5 abajo, se define el tipode sesion que describe el protocolo de este nuevo canal decomunicacion entre el Cajero y el Banco desde el punto devista del Cajero. Este tipo describe mediante el operador ! quepor este canal se envıa ahora un canal de comunicacion. Entrelos parentesis rectos que siguen al operador ! se tiene ahorael tipo que describe el uso del canal enviado. Luego de enviareste canal describimos el fin de la comunicacion mediante laprimitiva end. El Cajero utiliza el canal de comunicacion conel Cliente recibiendo primero su id y luego enviando la opcionfallo o exito segun corresponda, para finalmente enviar estecanal al Banco en caso que la autenticacion haya sido exitosa.Podemos entonces apreciar que el tipo del canal enviado es lacontinuacion del tipo presentado en la definicion 2 luego dela seleccion de la opcion exito.

![ &{deposito : ?[nat]; ![nat]; end, retiro : ?[nat];⊕{dispensa : end

, sobregiro : end} ]; end(5)

El tipo de sesion complementario al anterior, o sea la des-cripcion del canal desde el punto de vista del Banco, se obtienesimplemente cambiando la primera aparicion del operador ! alcomienzo del tipo por su operador complementario ?. Podemosver en la definicion 6 una posible implementacion de un nuevoproceso Cajero′, donde ahora en la rama exitosa se acuerdaun nuevo canal de comunicacion representado por la variablez a traves del nombre de puerto b, mediante la expresionaccept b(z) in . . .. Por este canal se envıa luego el extremodel canal de comunicacion y utilizando la primitiva throw. Elprotocolo seguido por la variable de canal z es el especificadopor el tipo de sesion descrito anteriormente en la definicion 5.

Cajero′ = request a(y) in(y?(id) in

(if . . . then h / fallo; inactelse y / exito;

accept b(z) in(throw z[y]; inact)))

(6)

En 7 definimos un posible proceso dual al anterior corres-pondiente al Banco. En este ejemplo el Banco primero acuerdaun nuevo canal de comunicacion representado por la variablede canal u a traves del puerto b. Por este canal posteriormenterecibe el canal de comunicacion v mediante la primitiva catch(operacion dual a throw). Luego a traves del canal v recibido,el Banco se comunica con el Cliente. De esta forma el Bancopuede terminar el trabajo hecho por el Cajero en el ejemploanterior. El canal u respeta la especificacion de comunicaciondada por el tipo dual al presentado en la definicion 5.

Banco = request b(u) in(catch u(v) in

(v . {deposito : v?(cantidad) in(. . . ;v![saldo];inact)

, retiro : v?(cantidad) in(if . . . then v / dispensar;

inactelse v / sobregiro;

inact)}))(7)

Componemos en paralelo ahora estos dos procesos con elproceso Cliente definido anteriormente para obtener el procesoque representa el sistema en su totalidad.

Cliente | Cajero′ | Banco

II-C. Calculo de Procesos

En esta seccion introducimos las definiciones completasdel calculo de procesos basados principalmente en [20], queincluye la sintaxis de los procesos y su semantica operacional.

La definicion inductiva del conjunto de los procesos sepresenta en la figura 1.

Los nombres de variables, de variables de canal y depuertos se denotan por a, b, . . . , x, y, . . .. Las constantes queincluyen a los conjuntos mencionados antes, y ademas los ente-ros y booleanos, son denotadas por c, c′, . . .. Las expresiones

P ::= request a(x) in P pedir sesion| accept a(x) in P aceptar sesion| k![e];P enviar informacion| k?(x) in P recibir informacion| k / lj ;P seleccionar etiquetas| k . {l1:P1 . . . ln:Pn} bifurcar internamente| throw k[k′];P enviar canal| catch k(x) in P recibir canal| if e then P else Q bifurcar| P | Q componer en paralelo| inact inaccion| (νa)P ocultar puerto| (νκ)P ocultar canal| def D in P recursion| X[ek] variables de proceso

e ::= c constantes| e+ e | e− e | e× e | not(e) | . . . operadores

D ::= X1(x1y1) = P1 and . . . Xn(xnyn) = Pn recursionk ::= x variable de canal

| κp valoresp ::= + | − polaridades

Figura 1. Sintaxis de los Procesos

son denotadas con e, e′, . . . y las etiquetas por l, l′, . . .. Lasvariables de procesos se denotan por X,Y, . . . y los procesosmediante P,Q, . . ..

Las variables x, y . . . son ligadas por las siguientes ex-presiones: k?(x) in P , X(xy) = P , request a(x) in P ,accept a(x) in P , y catch k(x) in P . Los nombres a, . . .son ligados en la expresion: (νa)P . Los canales y las variablesde procesos en cambio solo son ligados en las expresiones:(νκ)P y def D in P respectivamente. Para un procesoP , fpv(P ) denota el conjunto de las variables de procesoslibres en P , fn(P ) denota los nombres de variables comunesy de puertos libres, mientras que fc(P ) denota los canaleslibres en P . Se define fu(P ) = fn(P ) ∪ fc(P ). Tambien sedefine dpv(X1(x1y1) = P1 and . . . Xn(xnyn) = Pn) ={X1, . . . , Xn}.

La congruencia estructural es la relacion mas pequenade congruencia en procesos que incluye las ecuaciones de lafigura 2.

P ≡ Q if P ≡α QP | inact ≡ P P | Q ≡ Q | P (P | Q) |R ≡ P | (Q | R)

(νu)P | Q ≡ (νu)(P | Q) si u /∈ fu(Q)(νu)inact ≡ inact

def D in inact ≡ inact(νu)def D in P ≡ def D in (νu)P si u /∈ fu(D)

(def D in P ) | Q ≡ def D in (P | Q) si dpv(D) ∩ fpv(Q) = ∅(def D in (def D′ in P ) ≡ def D and D′ in P si dpv(D) ∩ dpv(D′) = ∅

Figura 2. Congruencia estructural

La semantica operacional de este calculo se define median-te la relacion de reduccion entre procesos, denotada por →.Esta relacion es definida como la menor relacion generada porlas reglas definidas en la figura 3, donde e ↓ c significa que laexpresion e evalua a la constante c.

Notese que en la semantica operacional se utilizan nombresde canales polarizados. El calculo de procesos con polaridadesfue introducido en [22], cuando originalmente los Tipos deSesion fueron definidos sin polaridades. En [21] se explica

(accept a(x) in P1) | (request a(x) in P2)→ (νκ)(P1[κ+/x] | P2[κ-/x])

(κp![e];P1) | (κp?(x) in P2)→ P1 | P2[c/x] si (e ↓ c)(κp / li;P ) | (κp . {l1:P1, . . . , ln:Pn})→ P | Pi con (1 ≤ i ≤ n)

(throw κp[κ′q ];P1) | (catch κp(x) in P2)→ P1 | P2[k′q/x]if e then P1 else P2 → P1 si (e ↓ true)if e then P1 else P2 → P2 si (e ↓ false)

P → P ′ ⇒ (νu)P → (νu)P ′

P → P ′ ⇒ P | Q→ P ′ | Q]P → P ′ ⇒ def D in P → def D in P ′

(P ≡ P ′) ∧ (P ′ → Q′) ∧ (Q′ ≡ Q)⇒ (P → Q)def D in (X[eκp] | Q)→

def D in (P [c/x][κp/y] | Q) si (e ↓ c) ∧ (X(xy) = P ∈ D)

Figura 3. Reduccion

detalladamente por que fueron introducidas las polaridades enel calculo de procesos. Tambien distingue entre el lenguaje deprogramacion, o sea el sub calculo de procesos a ser utilizadopor los programadores, y el lenguaje utilizado en tiempode ejecucion o runtime. Establece que los programadores nodeben lidiar con los canales directamente sino manipularlosa traves de variables de programacion convencionales. Loscanales son entidades que solo aparecen en tiempo de eje-cucion (al aplicar reducciones), finalmente sustituyendo a lasvariables en el codigo. Esta ultima afirmacion se puede apreciaren los ejemplos introducidos hasta el momento, donde noaparecen canales con polaridades en las distintas definicionesde procesos dadas.

II-D. Sistema de Tipos

Presentamos ahora la definicion inductiva del sistema deasignacion de tipos a procesos (Sistema de Tipos).

En la figura 4 se define la sintaxis de los tipos. MedianteS se denota al conjunto de los tipos comunes (Sorts), mientrasque α define los Tipos de Sesion o simplemente tipos.

S ::= nat | bool | 〈α, α〉α ::= ?[S];α | ?[α];α

| ![S];α | ![α];α| &{l1:α1 . . . ln:αn}| ⊕{l1:α1 . . . ln:αn}| µt.α| t| end

Figura 4. Sintaxis de los tipos

La expresion µt.α introduce la recursion en los tipos, ydenota que el canal comienza comportandose segun α y cuandot es encontrado, recomienza el comportamiento dictado por α.

Definimos a continuacion la funcion complemento quedevuelve el tipo de sesion dual o complementario a otro tipode sesion dado.

?[S];α =![S];α ⊕{li:αi}i∈I = &{li:α}i∈I ?[α];β =![α];β

![S];α =?[S];α &{li:αi}i∈I = ⊕{li:α}i∈I ![α];β =?[α];β

end = end µt.α = µt.α t = t

(8)

En la siguiente figura se presenta el sistema completo deasignacion de tipos a procesos con polaridades tal cual espresentado en [20]1.

Γ · a:S ` a . S [NAMEI] Γ ` 1 . nat [NAT] Γ ` true . bool[BOOL]

Γ ` ei . nat [SUM]Γ ` e1 + e2 . nat

Figura 5. Sistema de asignacion de tipos a expresiones

∆ solo contiente tipos end[INACT]

Θ; Γ ` inact .∆

Γ ` a . 〈α, α〉 Θ; Γ ` P .∆ · x:α[ACC]

Θ; Γ ` accept a(x) in P .∆

Γ ` a . 〈α, α〉 Θ; Γ ` P .∆ · x:α[REQ]

Θ; Γ ` request a(x) in P .∆

Γ ` e . S Θ; Γ ` P .∆ · k:α[SEND]

Θ; Γ ` k![e];P .∆ · k:![S];α

Θ; Γ · x:S ` P .∆ · k:α[RCV]

Θ; Γ ` k?(x) in P .∆ · k:?[S];α

Θ; Γ ` P1 .∆ · k:α1 . . . Θ; Γ ` Pn .∆ · k:αn [BR]Θ; Γ ` k . {l1:P1 . . . ln:Pn} .∆ · k:&{l1:α1 . . . ln:αn}

Θ; Γ ` P .∆ · k:αj(1 ≤ j ≤ n)[SEL]

Θ; Γ ` k / lj ;P .∆ · k:⊕ {l1:α1 . . . ln:αn}

Θ; Γ ` P .∆ · k:β[THR]

Θ; Γ ` throw k[k′];P .∆ · k:![α];β · k′:α

Θ; Γ ` P .∆ · k:β · x:α[CAT]

Θ; Γ ` catch k(x) in P .∆ · k:?[α];β

Θ; Γ ` P .∆ Θ; Γ ` Q .∆′[CONC]

Θ; Γ ` P | Q .∆⊗∆′

Γ ` e . bool Θ; Γ ` P .∆ Θ; Γ ` Q .∆[IF]

Θ; Γ ` if e then P else Q .∆

Θ; Γ · a:S ` P .∆[NRES]

Θ; Γ ` (νa)P .∆

Θ; Γ ` P .∆ · κ+:α · κ−:α[CRES]

Θ; Γ ` (νκ)P .∆

Θ; Γ ` P .∆ κ+ /∈ ∆ ∧ κ- /∈ ∆[CRES’]

Θ; Γ ` (νκ)P .∆

∆ solo contiente tipos end Γ ` e . S[VAR]

Θ ·X:Sα; Γ ` X[ek] .∆ · k:α

1Introducimos una pequena modificacion en la regla [CONC], en donderenombramos la operacion . por ⊗. Esta operacion, al igual que ., exige quelos contextos sean disjuntos para poder ası unirlos

Θ ·X:Sα; Γ · x:S ` P .∆ · k:α Θ ·X:Sα; Γ ` Q .∆[DEF]

Θ; Γ ` def X(xk) = P in Q .∆

Figura 6. Sistema de asignacion de tipos a procesos

En [20] se demuestra que este calculo tiene la propiedadde subject reduction, el cual establece que si un procesoP es tipable en ciertos contextos bajo las reglas de tipadopresentada en II-D, y P reduce a Q, entonces Q es tipablebajo los mismos contextos. A partir de este resultado tambiense demuestra la propiedad de type safety, que establece que siun proceso es tipable entonces nunca reduce a un error. Paraformalizar la nocion de type safety y de error se definen lossiguientes conceptos: un k−proceso es cualquier proceso queen su primera accion involucra al canal k (como por ejemplok![e];P o catch k(x) in P ); un proceso k−reducible es lacomposicion en paralelo de dos k−procesos de alguna de lassiguientes formas:

(κp![e];P1) | (κp?(x) in P2)

(κp / li;P )) | (κp . {l1:P1, . . . , ln:Pn})

(throw κp[k′q];P1) | (catch κp(x) in P2)

Entonces un proceso P es un error si contiene k−procesoscompuestos en paralelo que no son k−reducibles, para algunk.

II-E. Weakening de Contextos

La operacion de debilitamiento (weakening) de los contex-tos permite agregar informacion a los contextos de tipado. Pre-sentamos la propiedad que afirma que esta operacion preservala validez del juicio de tipado, bajo la premisa de no sobreescri-bir informacion ya existente en el contexto (weakening lemma).Utilizaremos este resultado para justificar la formalizacion delsistema de tipos, y tambien la demostracion de correccion delalgoritmo de inferencia de tipos mas adelante.

Teorema 2.1 (Weakening Lemma): Sean Θ, Γ, ∆ y Ptales que se satisface Θ; Γ ` P .∆.

Entonces se satisfacen las siguientes afirmaciones:

1. Si X /∈ dom(Θ) , entonces Θ ·X:Sα; Γ ` P .∆.2. Si a /∈ dom(Γ) , entonces Θ; Γ · a:S ` P .∆.3. Si k /∈ dom(∆) , entonces Θ; Γ ` P .∆ · k:end.

Prueba: La demostracion de este lema es por induccionen el arbol de derivacion de Θ; Γ ` P . ∆, y puede verse sudesarrollo completo en el apendice de la version completa deesta tesis [18].

II-F. Ejemplo de Delegacion de Canales

Finalmente, presentamos un ejemplo sencillo que utiliza-remos en lo que resta de este trabajo para ejemplificar las no-ciones a formalizar. En este ejemplo se delega un canal de co-municacion a traves de la pareja de primitivas throw−catchya vistas. Presentaremos la verificacion completa del tipo delproceso bajo el sistema de reglas visto, y en la seccion IVcomprobaremos que este tipo es efectivamente el mismo que elhallado por nuestro algoritmo de inferencia de tipos. Elegimos

(request a(x) in

P1︷︸︸︷(catch x(y) in (y![3, true]; inact)))

| (accept a(z) in (

P2︷︸︸︷(accept b(u) in (throw z[u]; inact))

|

P3︷︸︸︷(request b(v) in (v?(w, o) in inact))))

(9)

Figura 7. Proceso que delega un canal

este ejemplo debido a que utiliza las principales primitivas delcalculo sin ser demasiado extenso.

Podemos identificar tres procesos concurrentes, los cualesllamamos: P1, P2 y P3. Al comienzo existen solamente dosprocesos compuestos que acuerdan canales de comunicaciona traves del puerto a. El primer proceso identifica este canalde comunicacion como x y pasa a ejecutar el proceso P1,mientras que el segundo lo identifica como z, y luego sesubdivide, mediante otra composicion paralela, en dos procesosconcurrentes, los cuales identificamos como P2 y P3. Estosultimos acuerdan otro canal de comunicacion a traves delpuerto b, que es llamado u dentro de P2 y v dentro de P3.Luego el proceso P2 delega el canal u al proceso P1 a travesdel canal de comunicacion z, al cual P1 nombra como y.Finalmente el proceso P1 envıa informacion al proceso P3

a traves de este canal delegado.

Utilizamos el sistema de reglas de asignacion de tipospara comprobar que este ejemplo es tipable bajo el con-texto Γ = {a:〈α, α〉, b:〈β, β〉}, con α =! [β] ; end, y β =![nat, bool]; end, y los restantes contextos vacıos. Aplicamoslas reglas desde la conclusion hacia las premisas, en sentido“de abajo hacia arriba” o bottom-up. Comenzamos aplicandola regla [CONC] con los contextos anteriormente descritos, conlo cual debemos tipar los dos subprocesos que componen elproceso completo bajo los mismos contextos. Podemos vergraficamente el final de esta deduccion en la figura 8

... (figura 9)[REQ]

∅,Γ ` requesta(x) in P1

. ∅

... (figura 11)[ACC]

∅,Γ ` accepta(z) in P2|P3

. ∅[CONC]

∅,Γ ` request a(x) in P1

| accept a(z) in P2|P3. ∅

Figura 8. Ejemplo de asignacion de tipos a un proceso

Estudiamos ahora la rama izquierda de esta derivacion.Podemos ver en la figura 9 las inferencias de tipado seguidasen esta rama. Comenzamos aplicando la regla [REQ], queexige, por un lado que se cumpla el juicio de expresionesΓ ` a.〈α, α〉, el cual se cumple aplicando la regla [NAMEI] dela figura 5. Por otro lado [REQ] exige que el proceso que sigueal request sea tipable bajo los mismos contextos, solamenteagregando la informacion de que la variable de canal x tieneque tener tipo α (pidiendo ası que la variable de canal x seautilizada siguiendo la especificacion brindada por el contextoΓ para el puerto a). Aplicando la regla [CAT] se tiene queel tipo α debe ser de la forma ?[α′];β′, lo cual se cumpleya que definimos α =?[β]; end. Siguiendo esta regla tenemos

que el proceso y![3, true]; inact tiene que ser tipable bajolos mismos contextos que antes, salvo el de puertos que tieneque tener la continuacion del tipo α (o sea end) asignada ala variable de canal x. Esta regla tambien asigna el tipo desesion β a la nueva variable y que aparece en el alcance delcontexto.

[NAMEI]Γ ` a . 〈α, α〉

... (figura 10)[SEND]

∅,Γ ` y![3, true];inact

.

{x:end,y:![nat, bool]; end

}[CAT]

∅,Γ ` P1 . {x:α}[REQ]

∅,Γ ` request a(x) inP1 . ∅


En la figura 10 vemos que el proceso y![3, true]; inacttipa correctamente en los contextos descritos anteriormente,finalizando ası la derivacion de tipos en esta rama.

[NAT]∅ ` 3 . nat

[BOOL]∅ ` true . bool

{x:end,y:end

} solocontiene

tipos end

∅,Γ ` inact .

{x:end,y:end

}∅,Γ ` y![3, true]; inact .

{x:end,y:![nat, bool]; end

}Figura 10. Ejemplo de asignacion de tipos a un proceso

Retomamos ahora la rama derecha del arbol de la figura 8.En la figura 11 vemos el comienzo de la derivacion de tipospara esta rama: la regla [ACC] abre dos ramas. En la ramaizquierda se verifica que el contexto Γ brinde informacion delpuerto a, lo cual se satisface y el tipo asignado a este puertoes 〈α, α〉. En la rama derecha se pide que el proceso que sigueal accept tipe asignando a la variable de canal z el tipo desesion α en el contexto de canales.

[NAMEI]Γ ` a . 〈α, α〉

... (figura 12)[CONC]

∅,Γ ` P2|P3 . {z:α}[ACC]

∅,Γ ` a(z) in P2|P3 . ∅


En la figura 12 aplicamos la regla [CONC], la cual pideque los dos procesos que conforman la composicion paralelasean tipables bajo los mismos contextos de tipos de variablesde procesos y de puertos, pero el contexto de tipos de canalesse debe dividir de forma disjunta, dado que un mismo extre-mo de comunicacion no pueden ser usado por dos procesossimultaneamente. Ası dejamos la informacion de la variablede canal z en la rama izquierda, debido a que solamente enesa rama es usado el extremo de canal z.

... (figura 13)

∅,Γ ` P2 . {z:α}

... (figura 14)

∅,Γ ` P3 . ∅[CONC]

∅,Γ ` P2|P3 . {z:α}


En la figura 13 damos la continuacion de la derivacionde rama izquierda del arbol anterior, donde se aplica la regla[ACC], la cual pide que exista informacion para el puerto b enel contexto Γ, lo que se cumple ya que Γ asigna el tipo 〈β, β〉a el puerto b. Esta regla pide tambien que el resto del procesosea tipable agregando la asignacion de tipos u:β al contextode canales. Luego podemos aplicar la regla [THR] en la ramaderecha, debido a que α =![β]; end con lo cual el tipo de lavariable de canal z, o sea β, coincide con el tipo especificadocomo enviado por el tipo α. Terminamos esta rama aplicandola regla [INACT] dado que el contexto de canales contienesolamente tipos end.

[NAMEI]

Γ ` b . 〈β, β〉

{z:end} solo contiene tipos end[INACT]

∅,Γ ` inact . {z:end}[THR]

∅,Γ ` throw z[u];inact)

. {z:α, u:β}[ACC]

∅,Γ ` P2 . {z:α}


Finalmente, en la figura 14 vemos la ultima derivacion queresta detallar, correspondiente a rama derecha de la figura 12.En esta comenzamos aplicando la regla [REQ] que pide que elpuerto b tenga informacion de tipo en el contexto Γ, lo cual sesatisface ya que Γ asigna el tipo 〈β, β〉 a b. Esta regla tambienpide que el resto del proceso, sin la primitiva request, seatipable agregando la asignacion v:β al contexto de canales. Po-demos aplicar la regla [RCV] dado que β =?[nat, bool]; end,con lo cual agregamos al contexto Γ la informacion de tipode las variables w y o, y dejamos en el contexto de canalesla continuacion del tipo β, o sea end, a la variable de canalv. Quedan ası solo tipos end en el contexto de canales lo quepermite entonces aplicar finalmente la regla [INACT].

[NAMEI]

Γ ` b . 〈β, β〉

{v:end} solo contiene tipos end[INACT]

∅,Γ · {w:nat, o:bool} ` inact . {v:end}[RCV]

∅,Γ ` v?(w, o) ininact

.{v:β}

[REQ]∅,Γ ` P3 . ∅


III. INFERENCIA DE TIPOS DE SESION

En esta seccion presentamos el algoritmo de inferencia deTipos de Sesion propuesto en este trabajo. Dado un proceso sinninguna clase de declaraciones de tipos, el algoritmo infiere,si es que existen, los contextos de tipos mas generales bajo loscuales se satisface el juicio de tipado para este proceso.

A los efectos de acotar el alcance de este trabajo, queimplica la formalizacion rigurosa en Teorıa Constructiva deTipos del calculo de Tipos de Sesion, hemos quitado y sim-plificado algunas primitivas del calculo original, y adaptadocoherentemente las reglas del sistema de Tipos de Sesion.

III-A. Calculo de Procesos

Presentamos el sistema a formalizar, un calculo de procesossin polaridades que es un fragmento del definido en [20].

Quitamos las primitivas de seleccion ([SEL]) y bifurcacion so-bre etiquetas ([BR]), bifurcacion condicional ([IF]) y recursion([VAR] y [DEF]).

Removimos las polaridades del calculo porque estas soloaparecen en tiempo de ejecucion, como ya fue mencionado enla seccion anterior.

Por otro lado, las reglas de tipado asociadas a las primitivaseliminadas no son esenciales para el sistema de tipos. Porejemplo, las bifurcaciones condicionales tal cual son tratadasen [20], donde se exige que las ramas tengan tipos identicos,pueden introducirse de forma sencilla al sistema de tipos. Sien cambio queremos permitir que las bifurcaciones no tenganque tener tipos identicos y permitir subtipos, como en [22],entonces se debe introducir una relacion de subtipado (ordenparcial sobre los tipos) en el sistema de tipos.

Tambien las primitivas de seleccion y bifurcacion sobreetiquetas se pueden agregar facilmente en el sistema de tipospresentado, tal cual es expuesto en [22]. De la misma formaque antes para la bifurcacion condicional, se vuelve deseableun sistema de tipos con una relacion de subtipado, que acepteque dos procesos se comuniquen entre sı, si uno ofrece unabifurcacion con mas etiquetas que las usadas por el otroproceso.

Otra simplificacion realizada fue quitar los operadores delas expresiones reduciendo las mismas a variables y constantes,pero estos pueden ser introducidos sin mayor dificultad.

Finalmente el caso de la recursion es distinto ya que intro-duce mas complejidad al sistema de tipos, en [17] indicamoscomo puede ser tratado.

En la figura 15 definimos el calculo de procesos simplifi-cado segun lo descrito anteriormente.

P ::= request a(x) in P pedir sesion| accept a(x) in P aceptar sesion| k![e];P enviar informacion| k?(x) in P recibir informacion| throw k[k′];P enviar canal| catch k(x) in P recibir canal| P | Q componer en paralelo| inact inaccion| (νa)P ocultar puerto| (νκ)P ocultar canal

e ::= a variables de nombres| n constantes naturales| true constantes booleanas| false

k ::= x variable de canal| κ constante de canal

Figura 15. Sintaxis reducida de los procesos

III-B. Sistema de Tipos

En realidad el sistema de tipos presentado en la seccionanterior es polimorfico a la Curry [26], esto es, existenprocesos que admiten varias asignaciones de tipos bajo lasreglas de tipado introducidas en 6. Ejemplos de procesospolimorficos son:

accept a(x) in (x?(y) in (x![y].end))

accept a(x) in (accept b(y) in (throw x[y]; inact))

En estos procesos se le puede asignar cualquier tipo a lavariable y. Esto motiva la introduccion de variables de tipoque permitan modelar los tipos polimorficos, pasando a teneresquemas de tipos.

A diferencia de [20] donde se define que el conjunto delos tipos basicos y de puertos Sorts como un unico conjuntodenotado Sorts, nosotros decidimos dividir a este conjunto endos. De esta forma cortamos la circularidad que existe enla definicion de tipos presentada en la figura 4, lo cual nospermite definir dos conjuntos inductivos por separado. Conesta division perdemos la posibilidad de enviar puertos decomunicacion a traves de los canales. A pesar de esto, un pro-ceso puede seguir comunicandose con procesos no conocidos,mas especıficamente a los procesos conocidos por un procesoya conocido que actue como una especie de “proxy”, quedelegue todo lo recibido al proceso original. Tambien puedelograrse esto haciendo que el proceso ya conocido delegue uncanal de comunicacion con el proceso desconocido, mediantelas primitivas throw y catch, de forma similar al ejemplopresentado en la figura 7.

Introducimos ası en la figura 16 la sintaxis de los tiposdefinida a partir de la ya presentada en la seccion II-D conel cambio explicado en el parrafo anterior, quitando los tiposrecursivos y agregando a su vez variables de tipo.

Sintaxis Descripcion ContextoS ::= nat | bool | n Tipos basicos Φ

α ::= ?[S];α Tipos de los canales ∆

| ![S];α| ?[α];α| ![α];α| end| a| a

T ::= 〈α, α〉 Tipos de los puertos Γ

Figura 16. Sintaxis de los tipos

Utilizamos dos clases de variables de tipos: variables detipos basicos n y variables de tipos de canales a. Ademastambien introducimos el esquema de tipos a que al aplicarleuna sustitucion a 7→ α se instancia en α, o sea, el tipocomplementario a α.

A partir de esta definicion de tipos actualizamos en ladefinicion 10 la funcion que devuelve el tipo dual o comple-mentario de un tipo dado.

?[S];α =![S];α ?[α];β =![α];β

![S];α =?[S];α ![α];β =?[α];β

a = a a = a

end = end

(10)

El origen del polimorfismo en el sistema de tipos, masespecıficamente en los tipos de canal, surge a raız de la regla[THR], la cual introducimos en la figura 6, y repetimos acontinuacion.

Θ; Γ ` P .∆ · k : β[THR]

Θ; Γ ` throw k[k′];P .∆ · k :![α];β · k′ : α

Si leemos esta regla de arriba hacia abajo puede observarseque α es un tipo de canal de comunicacion cualquiera, y nohay informacion sobre este en las premisas.

Por otro lado el polimorfismo en los tipos basicos y depuertos se debe a las reglas [RCV] y [SEND] dadas en lafigura 5. Recordamos a continuacion la primera de estas reglas.

Θ; Γ · x : S ` P .∆ · k : α[RCV]

Θ; Γ ` k?(x) in P .∆ · k :?[S];α

Leyendo nuevamente esta regla de arriba hacia abajo, siel proceso P no brinda informacion para alguna variable xperteneciente al vector x, el contexto Γ no va tener informacionde tipos para x. En este caso estamos en las hipotesis delweakening lemma presentado anteriormente. Aplicando esteresultado podemos entonces asignar un tipo S cualquiera ala variable x.

Γ ` e . S Θ; Γ ` P .∆ · k:α[SEND]

Θ; Γ ` k![e];P .∆ · k:![S];α

De forma similar en la regla [SEND] si en el procesoP no se tiene informacion que permita inferir el tipo paraalgun nombre n perteneciente al vector e, el contexto Γ nova contener informacion de este nombre. Estamos entoncesen las hipotesis del weakening lemma (parte 2) nuevamente.Aplicando este lema a la segunda premisa de esta regla,obtenemos que podemos asignar un tipos S′ cualquiera a n, osea tenemos que se satisface Θ; Γ·n:S′ ` P.∆·k:α. Aplicandoahora un resultado de weakening similar al anterior pero parael juicio de expresiones a la primer premisa, obtenemos queΓ ·n:S′ ` n.S, con lo cual finalmente tenemos que S = S′, osea corroboramos que el juicio de tipado permite la asignacionde cualquier tipo basico S′ a n.

Debido a la division en dos del conjunto de los tiposbasicos y los de puertos decidimos dividir tambien el co-rrespondiente contexto en los juicios de tipado, subdividiendoası el contexto Γ del juicio ya presentado en la figura 6 enlos contextos de variables de tipos basicos Φ y de variablesde tipos de puertos Γ. Por otra parte quitamos el contexto devariables de procesos, y consistentemente quitamos al Sistemade Tipos las reglas correspondientes a las primitivas del calculoquitadas.

Finalmente, dado que el calculo de procesos definido notiene canales polarizados la regla [CRES] desaparece, y lacondicion κ+ /∈ ∆ ∧ κ- /∈ ∆ de la regla [CRES’] se vuelvetrivial, pudiendo ası eliminarla de las premisas del juicio.

Definimos en la figura 17 el sistema de asignacion de tiposresultante para expresiones, y en 18 para procesos respectiva-mente.

Γ · a:S ` a . S [VARS∈] Γ ` 1 . nat [NUM]

Γ ` true . bool[BOOLEAN]

Figura 17. Sistema de asignacion de tipos a expresiones

∆ solo contiene tipos end[INACT]

Φ; Γ ` inact .∆

Γ ` a . 〈α, α〉 Φ; Γ ` P .∆ · x:α[ACC]

Φ; Γ ` accept a(x) in P .∆

Γ ` a . 〈α, α〉 Φ; Γ ` P .∆ · x:α[REQ]

Φ; Γ ` request a(x) in P .∆

Φ ` e . S Φ; Γ ` P .∆ · k:α[SEND]

Φ; Γ ` k![e];P .∆ · k:![S];α

Φ · x:S; Γ ` P .∆ · k:α[RCV]

Φ; Γ ` k?(x) in P .∆ · k:?[S];α

Φ; Γ ` P .∆ · k:β[THR]

Φ; Γ ` throw k[k′];P .∆ · k:![α];β · k′:α

Φ; Γ ` P .∆ · k:β · x:α[CAT]

Φ; Γ ` catch k(x) in P .∆ · k:?[α];β

Φ; Γ ` P .∆ Φ; Γ ` Q .∆′[CONC]

Φ; Γ ` P | Q .∆⊗∆′

Φ; Γ · a:T ` P .∆[NRES]

Φ; Γ ` (νa)P .∆

Φ; Γ ` P .∆[CRES’]

Φ; Γ ` (νκ)P .∆

Figura 18. Sistema de asignacion de tipos a procesos

III-C. Algoritmo de Inferencia de Tipos

Denotamos mediante Γ(x) al tipo asignado a la variable xpor el contexto Γ, mientras que Γθ denota la aplicacion de lasustitucion θ a todos los tipos que aparecen en Γ. Notar quelas sustituciones θ aplican tanto a variables de tipos basicos,como a variables de tipos de canales. La expresion Γ <+x:αdenota sobrescribir el contexto Γ con la asignacion del tipo αa la variable x, Γ\x denota la eliminacion de la informacionde tipos de la variable x en Γ si es que esta existe, y Γ1 ∪ Γ2

representa la union de los contextos la cual esta bien definidasolo en caso de ser disjuntos en su dominio. Esta notacion seextiende con el mismo significado a los contextos Φ y ∆.

Primero presentamos el sistema de inferencia de tipos paralas expresiones del calculo en la figura 19.

La expresion Φ ` e ↪→ S,Φ′ denota que para la expresione se infiere el tipo S bajo el contexto de tipos basicos Φ, y asu vez en Φ′ retorna la asignacion de variables de tipos hechasi es que e es un nombre que no aparecıa en el contexto Φ,tal cual se puede observar en la regla [NAMEINFV].

Φ ` true, false ↪→ bool, ∅ [BOOLINF] Φ ` 1 ↪→ nat, ∅ [NATINF]

a ∈ dom(Φ)[NAMEINF]

Φ ` a ↪→ Φ(a), ∅

a 6∈ dom(Φ) n variable de tipo basicos fresca[NAMEINFV]

Φ ` a ↪→ n, {a:n}

Figura 19. Sistema de inferencia de tipos en expresiones

Observar que el sistema de reglas para el tipado de expre-siones anterior define correctamente un algoritmo, dado queestas reglas son dirigidas por la sintaxis de las expresiones.

Dada una expresion cualquiera queda determinado que re-gla usar observando la forma de la expresion, con lo cuales directa la traduccion de estas reglas a cualquier lenguajefuncional con concordancia de patrones (pattern matching).Extendemos este algoritmo para listas de expresiones, denota-mos la aplicacion de esta extension a un vector de expresionese y un contexto de tipos basicos Φ de la siguiente formaΦ ` e ↪→ S,Φ′, donde se retorna el vector de tipos basicosS resultado de aplicar el algoritmo de la figura 19 a cadaexpresion de la lista e, donde Φ′ almacena las asignaciones devariables frescas hechas. Calculamos Φ′ llevando un acumula-dor ac donde se van agregando las asignaciones de variablesfrescas hechas al ir aplicando el algoritmo a cada expresioncon argumento Φ∪ac (o sea al inferir el tipo de cada expresionusamos ademas del contexto Φ la informacion de asignacion detipos recabada hasta el momento en ac). Finalmente, cuando seterminan de recorrer el vector de expresiones, devolvemos esteacumulador como resultado Φ′. Notar que este procedimientoasegura que el contexto Φ′ no tenga nombres repetidos, o sea,mas de una asignacion de tipo para algun nombre.

Para la implementacion del algoritmo de inferencia paraprocesos tomamos al contexto ∆ como una funcion total, lacual asigna el tipo de canal end para canales no definidosen el contexto. Este comportamiento para el contexto ∆ noaparece explıcitamente en sistema de tipos dado en [20] ypresentado en la seccion II-D, pero se puede comprobar quese cumple implıcitamente en la tercera parte del weakeninglemma presentado en el teorema 2.1, donde enunciamos quesi Θ; Γ ` P .∆ ∧ k /∈ dom(∆) ⇒ Θ; Γ ` P .∆ · k : end.El asumir que el contexto ∆ tiene informacion de cualquiercanal facilita la implementacion del algoritmo de inferencia,no necesitando entonces exigir explıcitamente que ∆ tengainformacion del canal k para que la aplicacion ∆(k) este biendefinida.

Utilizamos la expresionθt lst para denotar que la uni-

ficacion de una lista de pares de tipos de sesion lst tienecomo resultado la sustitucion θ. Finalmente Γ1 1 Γ2 denotala lista de pares ordenados de tipos resultante de emparejar lainformacion comun de puertos de Γ1 y Γ2.

Finalmente presentamos el algoritmo de inferencia de tipospara procesos en la figura 20.

La expresion Φ,Γ ←↩ P ↪→ ∆ denota que para elproceso P se infieren los contextos de tipado Φ, Γ y ∆.Consideramos a los contextos como funciones parciales denombres en tipos, salvo el contexto de canales que tomamoscomo una funcion total de canales en tipos de canal como yase explico anteriormente.

[INACTINF]∅, ∅ ←↩ inact ↪→ ∅

Φ,Γ←↩ P ↪→ ∆ a 6∈ dom(Γ)[ACCINF1]

Φ,Γ <+a:〈∆(x),∆(x)〉 ←↩ accept a(x) in P ↪→ ∆\x

Φ,Γ←↩ P ↪→ ∆ a ∈ dom(Γ)θt[

(fst(Γ(a)),∆(x)),

(snd(Γ(a)),∆(x))

][ACCINF2]

Φθ,Γθ ←↩ accept a(x) in P ↪→ (∆θ)\x

Φ,Γ←↩ P ↪→ ∆ a 6∈ dom(Γ)[REQINF1]

Φ,Γ <+a:〈∆(x),∆(x)〉 ←↩ request a(x) in P ↪→ ∆\x

Φ,Γ←↩ P ↪→ ∆ a ∈ dom(Γ)θt[

(fst(Γ(a)),∆(x)),(snd(Γ(a)),∆(x))

][REQINF2]

Φθ,Γθ ←↩ request a(x) in P ↪→ (∆θ)\x

Φ,Γ←↩ P ↪→ ∆ Φ ` e ↪→ S,Φ′[SENDINF]

Φ ∪ Φ′,Γ←↩ k![e];P ↪→ ∆ <+k:![S]; ∆(k)

Φ,Γ←↩ P ↪→ ∆ Φ ` x ↪→ S,Φ′[RCVINF]

Φ\x,Γ←↩ k?(x) in P ↪→ ∆ <+k:?[S]; ∆(k)

Φ,Γ←↩ P ↪→ ∆ ∆(k′) = end k 6= k′ avariable

de tipo decanal fresca

[THRINF]Φ,Γ←↩ throw k[k′];P ↪→ (∆ <+k:![a]; ∆(k)) <+k′:a

k 6= x Φ,Γ←↩ P ↪→ ∆[CATINF]

Φ,Γ←↩ catch k(x) in P ↪→ (∆ <+k:?[∆(x)]; ∆(k))\x

Φ1,Γ1 ←↩ P ↪→ ∆1 Φ2,Γ2 ←↩ Q ↪→ ∆2

θt

[(Γ1 1 Γ2π)

∪(Φ1 1 Φ2π)

][CONCINF]

Φ1θ ∪ Φ2πθ,Γ1θ ∪ Γ2πθ ←↩ P | Q ↪→ (∆1θ)⊗ (∆2πθ)

Φ,Γ←↩ P ↪→ ∆[NRESINF]

Φ,Γ\a←↩ (νa)P ↪→ ∆

Φ,Γ←↩ P ↪→ ∆[CRES’INF]

Φ,Γ←↩ (νκ)P ↪→ ∆

Figura 20. Algoritmo de inferencia de tipos en procesos

Nuevamente el sistema de reglas introducido ahora para eltipado de procesos es dirigido por la sintaxis de los procesos,a excepcion de las parejas de reglas [ACCINF1] y [ACCINF2]por un lado, y [REQINF1] y [REQINF2] por otro. En estoscasos solo observar la forma del proceso no permite saber cualde las reglas en cada pareja usar. Se debe entonces aplicar elalgoritmo recursivamente para luego estudiar si a ∈ dom(Γ)para el contexto Γ devuelto.

A continuacion comentamos cada regla. Comenzamos de-tallando la regla [INACTINF], la cual devuelve tres contextosvacıos para un proceso de la forma inact, dado que esteproceso no contiene nombres o variables a ser tipadas.

En el caso de un proceso de la forma accept a(x) in P ,como mencionamos antes, podemos aplicar tanto la regla[ACCINF1] como [ACCINF2]. Para decidir que regla usardebemos entonces aplicar el algoritmo al proceso P , si elresultado es que no hay contextos que tipen este procesoentonces el proceso original tampoco es tipable ya que nose cumplen las premisas de ninguna de las anteriores reglas.Si en cambio sı existen contextos Φ, ∆ y Γ que tipen Panalizamos si el puerto a aparece en el contexto Γ. Cuandoaparece aplicamos la regla [ACCINF2], y debemos entoncesresolver la tercer premisa de esta regla. Esta pide unificar:la primera componente del par (obtenida mediante la funcionfst) que conforma el tipo de puerto de a en el contexto Γcon el tipo asignado al canal x en ∆, y tambien la segundacomponente (obtenida mediante la funcion snd) en el tipode a con el complemento del tipo de x en ∆. Si no existeunificacion posible entonces el resultado es que el proceso noes tipable, al fallar la tercer premisa de esta regla. Cuandosı existe una sustitucion θ que unifique las dos parejas detipos descrita entonces devolvemos los contextos resultantes deaplicar las sustituciones a los contextos Φ, ∆ y Γ. Quitamosla informacion de tipo del canal x en ∆, ya que la primitiva

de procesos accept liga la variable x en P . Cuando a /∈ Γaplicamos la regla [ACCINF1] que consistentemente tambienquita la informacion del canal x de ∆, y la asigna a la variablede puerto a en su primera componente, y el complemento ensu segunda componente en el contexto Γ. El caso inductivorequest a(x) in P es similar.

Para un proceso k![e];P utilizamos la regla [SENDINF]que pide como premisas que el proceso P sea tipable bajocontextos Φ, ∆ y Γ, y con el mismo contexto de tipos basicosΦ como argumento, mas el vector de expresiones e, invocamosa la extension del algoritmo de inferencia en expresiones alistas de expresiones. Se devuelve finalmente los contextosΦ ∪ Φ′, Γ y ∆ agregandole la asignacion al canal k deltipo ![S]; ∆(k). El dominio de Φ′ solo contiene nombres queno pertenecen a Φ; esto es debido a que en la definiciondel algoritmo de inferencia en expresiones solo se agreganasignaciones de tipos a nombres a en la regla [NAMEINFV],y esta regla tiene como premisa que a 6∈ dom(Φ). Quedaentonces bien definida la union Φ ∪ Φ′.

En el caso en que el proceso sea de la forma k?(x) in Paplicamos la regla [RCVINF], que tiene como premisa que elproceso P sea tipable bajo contextos Φ, Γ y ∆, y en este casoen la segunda premisa invocamos al algoritmo de inferenciaen expresiones con argumentos Φ y x. Retornamos el contextoΓ inalterado, a Φ le quitamos la informacion de tipado paralas variables x, y a ∆ le agregamos la asignacion a k del tipo?[S]; ∆(k), donde S es el vector de tipos basicos resultante deaplicar el algoritmo de inferencia en expresiones.

Cuando el proceso es de la forma throw k[k′];P , aplica-mos la regla [THRINF] que pide que los canales k y k′ seandistintos, y aplicamos el algoritmo al proceso P . Si existencontextos Φ, ∆ y Γ que tipen P entonces comprobamos siel contexto ∆ contiene informacion del canal k′; en caso detener informacion devolvemos que el proceso original no estipable, debido a que el canal k′ es utilizado dentro de P . Si noaparece informacion del canal k′ en el contexto ∆ devolvemoslos contextos Φ y Γ inalterados, mientras que al contexto ∆le asignamos a k el tipo ![a]; ∆(k), y a k′ el tipo a. Aquı aes una variable de tipo de canal fresca, esto es, no aparece enlos contextos ∆ ni Γ.

Si el proceso es de la forma catch k(x) in P , aplicamosla regla [CATINF] que exige que k no sea una variable connombre x; en caso de serlo entonces el proceso no es tipable. Sino son identicos entonces aplicamos el algoritmo al proceso Ptal cual exige la segunda premisa de esta regla. Si P es tipablebajo contextos Φ, ∆ y Γ, devolvemos los contextos Φ y Γ sinmodificaciones, mientras que al contexto ∆ le asignamos alcanal k el tipo ?[∆(x)]; ∆(k). Finalmente, luego de agregaresta informacion, le quitamos la asignacion de tipos para lavariable de canal x, debido a que la variable x es ligada porla primitiva catch en P .

En el caso de un proceso de la forma P | Q utilizamos laregla [CONCINF] cuyas premisas piden que los procesos quecomponen la composicion en paralelo P y Q sean tipables. Siambos procesos son tipables bajo contextos Φ1, ∆1 y Γ1 , yΦ2, ∆2 y Γ2 para P y Q respectivamente, entonces la tercerpremisa pide unificar el conjunto de tuplas de tipos resultantede agrupar en pares la informacion de tipos de puertos encomun en Γ1 y Γ2, y de tipos basicos para nombres en comun

en Φ1 y Φ2. Antes de agrupar esta informacion renombramoslas variables de tipos en Γ2, Φ2 y ∆2 con nombres frescosrespecto de Γ1, Φ1 y ∆1. Este renombre lo representamosmediante una sustitucion π.

Para un proceso de la forma (νa)P utilizamos la regla[NRESINF] que pide que el proceso P sea tipable tambien poreste algoritmo bajo ciertos contextos. Se retorna entonces estosmismos contextos, salvo que quitamos el puerto a del contextode puertos ya que la primitiva νa liga el puerto en el procesoP

Finalmente cuando el proceso es de la forma (νκ)Pdevolvemos directamente el resultado de la llamada recursivapara el proceso P .

III-D. Solidez

Presentamos ahora los lemas previos y la demostracion dela solidez del algoritmo de inferencia definido en la seccionanterior con respecto al juicio de tipos definido en la figura 18.

Lema 3.1 (Solidez de la inferencia para expresiones):Φ ` e ↪→ S,Φ′ implica que el contexto Φ′ no contienenombres repetidos y sus asignaciones son todas a variablesde tipos frescas y, que se satisfacen ademas las siguientesafirmaciones:

Φ ∪ Φ′ ` e . S

dom(Φ′) ∩ dom(Φ) = ∅

dom(Φ′) ⊆ e

Prueba: La justificacion es directa viendo la definicionde este juicio.

Lema 3.2 (Weakening Lemma para el contexto Φ):Φ,Γ ` P .∆ y n 6∈ dom(Φ) implica que Φ · n:S,Γ ` P .∆.

Prueba: La demostracion de este resultado es por induc-cion en las reglas del juicio Φ,Γ ` P . ∆, y se detalla en elApendice del desarrollo completo de esta tesis [18].

Lema 3.3 (Weakening Lemma para el contexto Γ):Φ,Γ ` P.∆ y a 6∈ dom(Γ) implica que Φ,Γ·a:〈α, α〉 ` P.∆.

Prueba: Al igual que el anterior caso la demostracion deeste resultado es por induccion en las reglas del juicio Φ,Γ `P .∆, y se detalla en el Apendice de [18].

Lema 3.4 (Conservacion bajo sustituciones): Φ,Γ ` P .∆ implica Φθ,Γθ ` P .∆θ.

Prueba: Esta demostracion es por induccion en el juicioΦ,Γ ` P .∆.

Teorema 3.5 (Solidez de la inferencia para procesos):Φ,Γ←↩ P ↪→ ∆ implica Φ,Γ ` P .∆.

Prueba: La demostracion es por induccion en la defi-nicion inductiva del proceso P , la demostracion detallada esdesarrollada en la version completa de la tesis [18].

III-E. Completitud

En esta seccion probamos que nuestro algoritmo infiereel esquema de tipos principal (Principal Type Scheme) paracualquier programa tipable.

Definicion Decimos que un contexto Γ esta incluido amplia-mente en otro Γ′ (Γ ⊆ Γ′) si y solo si ∀a:S ∈ Γ (cada nombreque Γ brinde informacion de tipado S), a:S ∈ Γ′.

Definicion Decimos que un contexto ∆ de canales esta inclui-do ampliamente en otro ∆′ (∆ ⊆ ∆′) si y solo si se cumplenlas siguientes dos condiciones:

∀x:α ∈ ∆, x:α ∈ ∆′

∀x si 6 ∃α, x:α ∈ ∆ y ∃α, x:α ∈ ∆′ entonces α ≡ end.

Teorema 3.6 (Completitud de la inferencia para procesos):Si se satisface Φ,Γ ` P .∆, entonces ∃Φ′,Γ′,∆′, θ tales queΦ′,Γ′ ←↩ P ↪→ ∆′, Φ′θ ⊆ Φ, Γ′θ ⊆ Γ y ∆′θ ⊆ ∆.

Prueba: Hacemos induccion en la derivacion del juicioΦ,Γ ` P .∆. La demostracion detallada es desarrollada en laversion completa de la tesis [18].

III-F. Corolario de la Completitud

Corolario 3.7: Surge como corolario del resultado anteriorque si el algoritmo no encuentra solucion alguna, entonces parael proceso argumento no existen contextos bajo los cuales sesatisfazca el juicio de tipado.

IV. FORMALIZACION DE LA INFERENCIA DE TIPOS DESESION EN LA TEORIA CONSTRUCTIVA DE TIPOS

En el trabajo de tesis formalizamos el algoritmo de infe-rencia de tipos presentado en la seccion III-C utilizando elasistente de pruebas Agda. Para la implementacion utilizamosla version 2.2.6 del compilador y la version 0.3 de la bibliotecaestandar de Agda [7].

El algoritmo de inferencia de tipos recibe un proceso P einfiere los contextos de esquemas de tipos mas generales Φ,Γ y ∆ bajo los cuales se satisface el juicio Φ; Γ ` P . ∆introducido en la seccion III-B, si es que esto es posible.Demostramos en Agda el teorema 3.5 antes enunciado desolidez del algoritmo con respecto al sistema de tipos. Estoes, probamos que si el algoritmo de inferencia codificado enAgda infiere los contextos Φ, Γ y ∆ para un proceso P ,entonces necesariamente se satisface la formalizacion en TeorıaConstructiva de Tipos del juicio Φ; Γ ` P .∆.

Implementamos el algoritmo de inferencia de tipos me-diante recursion primitiva en la estructura del proceso P dadocomo argumento, aplicando segun corresponda las reglas delalgoritmo presentado en la figura 20. Al utilizar recursionprimitiva nos aseguramos la terminacion de dicho algoritmo.La codificacion del algoritmo de inferencia es directo salvolos algoritmos de unificacion que discutimos en la siguienteseccion.

IV-A. Formalizacion de los Algoritmos de Unificacion

Al presentar el algoritmo de inferencia en la seccion III-Cvimos la necesidad de encontrar una sustitucion θ que unifiqueuna lista de pares de tipos de sesion lst dada, lo cual aparece

denotado porθt lst en la regla [ACCINF1] del algoritmo de

inferencia. Definimos ası el problema de unificacion como elde encontrar una sustitucion que haga iguales a dos terminos,si es que es posible. Una sustitucion es una funcion queasigna terminos a variables, en nuestro caso Tipos de Sesiona variables de tipos pertenecientes a los esquemas de tipos.El problema de unificacion puede generalizarse para una listade pares de terminos a unificar, en cuyo caso la sustitucionresultado iguala a todos los pares de esta lista.

En este trabajo realizamos la formalizacion en Agda delos algoritmos de unificacion para los tipos basicos y para losTipos de Sesion. En la version completa de esta tesis [18]presentamos el codigo Agda y una explicacion precisa de lasprincipales definiciones y pruebas dejando algunos resultadosauxiliares en el apendice de la tesis.

Una introduccion detallada al problema de la unificacion determinos que son tipos del calculo lambda y su formalizacionen Teorıa Constructiva de Tipos utilizando el asistente depruebas Alf se puede encontrar en [6]. Nuestra formalizacionen Agda sigue los lineamientos generales de este trabajoadaptandolos de los tipos del calculo lambda a los Tipos deSesion, y utilizando el asistente de pruebas Agda en vez deAlf.

Utilizamos tambien a diferencia de [6] la formalizacion deinduccion bien fundada de la biblioteca estandar de Agda lacual introducimos tambien de forma detallada en el desarrollocompleto de esta tesis [18]. Este resultado permite definir fun-ciones por recursion general, siempre y cuando los argumentosdecrezcan de alguna forma y la relacion de orden sobre la cualdecrecen sea bien fundada. Demostrando ası la terminacionde los algoritmos de unificacion. Tambien demostramos lacorreccion de la unifiacion en tipos basicos.

La actual formalizacion de este trabajo supera las 5800lıneas de codigo Agda, de los cuales casi la mitad correspondena la formalizacion de la unificacion. Debido a esto, por razonesde tiempo, no completamos la formalizacion de correccion delalgoritmo de unificacion para los Tipos de Sesion. Sin embargoestimamos que la demostracion restante sigue basicamente laidea de la prueba ya realizada para el primero de los algoritmosde unificacion.

IV-B. Codificacion del Juicio de Asignacion de Tipos a losProcesos

En nuestra formalizacion utilizamos listas de pares orde-nados para codificar los contextos, estos pares asignan a cadavariable un cierto tipo. Debido a esto es necesario introducir lapropiedad de que el orden de los pares en los contextos no esrelevante, lo cual lo introducimos a traves de una regla extraen el juicio que establece justamente esta propiedad. En [20]esto se impone implıcitamente al definir que los contextos sonfunciones parciales.

Demostramos de forma completa todas las propiedadespresentadas anteriormente salvo una excepcion para la

cual debio asumirse la α-conversion en los procesos: Lademostracion de la segunda parte del weakening lemmapresentado en el teorema 2.1 se realizo por induccion enel juicio de tipado. En el caso inductivo de la regla Nresintroducida en la figura 6, es necesario suponer que parael proceso (νa)P se cumple que el puerto a′ agregado alcontexto es distinto de a. Dado que la primitiva ν liga alpuerto a en el proceso P , esta suposicion es correcta porser los procesos α-convertibles, pudiendose ası renombrar elpuerto a por otro nombre de puerto fresco b distinto de a′, yconsistentemente en P . Llamando P ′ al proceso resultante deeste renombrado, se obtiene un proceso (νb)P ′ α-equivalenteal proceso (νa)P original. Ahora se cumple que b 6= a′ ypodemos entonces aplicar el weakening lemma de formaexitosa sobre el proceso (νb)P ′. Dado que no formalizamos elconcepto de α-conversion debimos axiomatizar esta propiedadpara completar la demostracion del caso inductivo de la reglaNres.

IV-C. Solidez del Algoritmo de Inferencia de Tipos

Codificamos la demostracion de solidez del algoritmo deinferencia de tipos en el asistente de pruebas Agda. Esto es,probamos que si el algoritmo infiere los contextos Φ, Γ y ∆para un proceso P , entonces necesariamente se satisface eljuicio Φ; Γ ` P . ∆. Podemos comprobar en la figura 21 latransparente codificacion de este enunciado en Agda.

typeInferenceSoundness : (p : Process)(Φ : Sorts)(∆ : STypes)(Γ : Types)→ typeInf p ≡ just (Φ , ∆ , Γ)→ (Φ , Γ) ` p . ∆

Figura 21. Enunciado de solidez del algoritmo de inferencia de tipos

La demostracion de este resultado es por induccion en elproceso p. En el desarrollo completo de esta tesis describimoslos distintos casos de la induccion y presentamos algunos sublemas utiles para esta demostracion [18].

IV-D. Aplicacion del Algoritmo de Inferencia

Finalmente, en la figura 22 mostramos el resultado deaplicar el algoritmo de inferencia codificado en Agda alproceso presentado en la figura 7. Anteriormente en la figura 8comprobamos que este proceso tipa correctamente bajo ∆ = ∅,Φ = ∅ y Γ = {a : 〈α, α〉, b : 〈β, β〉}, con α =! [β] ; end, yβ =![nat, bool]; end.

En el desarrollo completo de esta tesis damos lacodificacion de este proceso en Agda. En esta codificamoslos puertos de comunicacion a y b mediante los naturales 1 y5 respectivamente. Ası ahora comprobamos que el algoritmode inferencia de tipos devuelve efectivamente el mismoresultado que ya fue comprobado manualmente. Por falta delugar no presentamos la codificacion de los Tipos de Sesioncompleta desarrollada en esta tesis. Sı explicamos comose corresponde el anterior resultado obtenido de correr elalgoritmo de inferencia con el obtenido manualmente en II-F.El prefijo just indica que existe un resultado exitoso dela inferencia de tipos, luego sigue una terna de listas, lasprimeras dos vacıas se corresponden a los contextos vacıos

Φ y Γ. La ultima componente de la terna esta formada porun contexto con dos tuplas que corresponde a Γ. La primeratupla de este contexto asocia al puerto a, codificado conel natural 1, una codificacion de un Tipos de Sesion quecomienza por el constructor par que agrupa dos Tipos deSesion que se corresponden a α y α descritos en el parrafoanterior. Finalmente la codificacion del Tipos de Sesion{![![nat, bool]; end]; end} que se asocia a α, se correspondea la codificacion (sendST (sendS (nat::boolean::[]) end)

end) hallada por nuestro algoritmo de inferencia.

just ([],[],(1,par (sendST (sendS (nat::boolean::[]) end)

end)(receiveST (sendS (nat::boolean::[]) end)

end))::(5,par (sendS (nat::boolean::[]) end)

(receiveS (nat::boolean::[]) end))::[])

Figura 22. Resultado del algoritmo de inferencia de tipos

V. CONCLUSION Y TRABAJO A FUTURO

La principal contribucion de este trabajo es la demostracionde que el teorema de existencia de esquema de tipo principalque vale para el calculo lambda simplemente tipado a la Curryse puede extender a los Tipos de Sesion. Ademas hemos dadouna formalizacion en la Teorıa Constructiva de Tipos de esteresultado. En terminos practicos, este teorema se traduce enque la condicion de compatibilidad en los dialogos entre pro-cesos concurrentes es verificable estaticamente sin necesidadde incluir anotaciones de tipos en los procesos. Este resultadono se encuentra en la literatura. El trabajo mas cercano es [25]pero aplica al calculo π y no es formalizado en un asistentede pruebas. En [27] realizan tambien una formalizacion en elasistente de pruebas Coq de un algoritmo de inferencia, masespecıficamente, para un fragmento del lenguaje ML. Pero nodemuestran la correccion de la unificacion, la cual axiomatizanpara completar la demostracion de correctitud del algoritmo deinferencia.

Este trabajo fue hecho para una simplificacion del calculode Tipos de Sesion pero conjeturamos que es extensible atodo el calculo. Queda como posible trabajo a futuro incluirla seleccion y aceptacion sobre etiquetas y, mas interesanteaun, la recursion en el sistema de tipos. Existen extensionesal calculo de los Tipos de Sesion original, como por ejemploMultiparty Sessions [28] que extienden la comunicacion a masde dos participantes. Otro posible camino entonces podrıa serextender el algoritmo de inferencia propuesto a alguna de estasextensiones.

El sistema de tipos y el algoritmo de inferencia fueronformalizados en Teorıa Constructiva de Tipos, mas especıfi-camente en el asistente de pruebas de Agda. Se comprobo elpoder de expresion de esta teorıa, la cual permitio formalizarde forma adecuada este trabajo. Sin embargo se encontraronciertos problemas al usar el compilador de Agda con pruebasde gran tamano, debido a los cuales se debio quitar el chequeode parada en los modulos que contienen los algoritmos de

unificacion, para ası lograr completar la compilacion de nues-tra formalizacion. Sin embargo estos modulos compilan porseparado correctamente con el chequeo de parada habilitado.

El algoritmo de inferencia de Tipos de Sesion requiere laimplementacion de la unificacion en esquemas de Tipos deSesion. Esta implementacion aunque se basa en algoritmosde unificacion estandares, requirio adaptar estos algoritmosdebido a la necesidad de unificar simultaneamente dos estruc-turas de tipos distintas pero interrelacionadas. Esto fue resueltomediante dos algoritmos de unificacion, donde uno de ellosutiliza al otro. Estos algoritmos utilizan dos clases de varia-bles de tipos, y sus correspondientes sustituciones asociadas.Ademas propusimos la idea de esquema complementario quefue necesaria para lograr resolver la unificacion en Tipos deSesion. La codificacion elegida para resolver la unificacion espoco extensible; esto es debido a que cualquier cambio enla estructura de los datos, termina impactando fuertemente enlos predicados de accesibilidad necesarios para demostrar laterminacion. Es necesario entonces en este caso reestructurar lademostracion de que se satisface el predicado de accesibilidad.En [29] resuelven el problema de unificacion de forma masgeneral utilizando estructuras arborescentes genericas, tal cualse explica en [30], y luego implementan una biyeccion dearboles en Tipos de Sesion. Sin embargo, resta estudiar comoimpacta esto sobre la formalizacion de las demostraciones.

Codificamos exitosamente la prueba de solidez del algo-ritmo de inferencia de Tipos de Sesion. Debido a problemasde tiempo quedo por demostrar la completitud del algoritmo,aunque brindamos una prueba informal de este resultado. Que-da como posible trabajo a futuro una formalizacion completade este resultado.

Otro detalle pendiente en esta tesis es la formalizacionadecuada del concepto de α-conversion, para ası obtener unaprueba de uno de los lemas de weakening del juicio detipado que no use el axioma que impone la α-conversion.Sin embargo en un trabajo posterior [17] resolvemos esteproblema mediante una reescritura del juicio de tipado quepermite demostrar este lema sin la necesidad de apelar a laα-conversion de los procesos.

AGRADECIMIENTOS

Deseo agradecer a mi padre que me oriento hacia laingenierıa, y a mi madre por motivar continuamente misestudios, a ambos por brindarme su apoyo incondicional.

Agradezco a Nora Szasz y Alvaro Tasistro la oportunidady la confianza depositada en mı al brindarme la posibilidadde realizar este trabajo, y por sobre todo la paternal amistadque me brindan. Tambien deseo reconocer que sus ensenanzas,contribuciones y correcciones fueron indispensables para estetrabajo.

Finalmente agradezco a la ANII (Asociacion Nacionalde Investigacion e Innovacion) por la beca otorgada para larealizacion de esta Maestrıa.

REFERENCIAS

[1] K. Honda, “Types for dyadic interaction,” in CONCUR’93, ser. LectureNotes in Computer Science, E. Best, Ed. Springer Berlin / Heidelberg,1993, vol. 715, pp. 509–523, 10.1007/3-540-57208-2 35. [Online].Available: http://dx.doi.org/10.1007/3-540-57208-2 35

http://dx.doi.org/10.1007/3-540-57208-2_35

[2] K. Honda, V. T. Vasconcelos, and M. Kubo, “Language primitives andtype disciplines for structured communication-based programming,” inESOP’98, ser. LNCS, vol. 1381. Springer, 1998, pp. 22–138. [Online].Available: http://www.di.fc.ul.pt/∼vv/papers/honda.vasconcelos.kubolanguage-primitives.pdf

[3] M. Dezani-ciancaglini, “Sessions and session types: an overview,” In6th International Workshop on Web Services and Formal Methods (WS-FM’09, Tech. Rep., 2010.

[4] W. A. Howard, “The formulas-as-types notion of construction,” in ToH. B. Curry: Essays on Combinatory Logic, Lambda Calculus, andFormalism, J. P. Seldin and J. R. Hindley, Eds. Academic Press, 1980,pp. 479–490, reprint of 1969 article.

[5] N. Szasz, “A theory of specifications, programs and proofs,” June 1997,phD thesis, Department of Computer Science, Chalmers University ofTechnology.

[6] A. Bove, “Programming in Martin-Lof type theory: Unification - A non-trivial example,” November 1999, licentiate Thesis of the Departmentof Computer Science, Chalmers University of Technology.

[7] A. Bove, P. Dybjer, and U. Norell, “A brief overview of agda - afunctional language with dependent types,” in Theorem Proving inHigher Order Logics, 22nd International Conference, TPHOLs 2009,ser. LNCS, S. Berghofer, T. Nipkow, C. Urban, and M. Wenzel, Eds.,vol. 5674. Springer, August 2009, pp. 73–78.

[8] A. Bove and P. Dybjer, “Dependent types at work,” in LanguageEngineering and Rigorous Software Development International LerNetALFA Summer School, ser. LNCS, A. Bove, L. Barbosa, A. Pardo, andJ. S. Pinto, Eds., vol. 5520. Springer, 2009, pp. 57–99.

[9] U. Norell, “Dependently typed programming in agda,” in TLDI, A. Ken-nedy and A. Ahmed, Eds. ACM, 2009, pp. 1–2.

[10] M. Neubauer and P. Thiemann, “An implementation of session types,”in PADL, ser. Lecture Notes in Computer Science, B. Jayaraman, Ed.,vol. 3057. Springer, 2004, pp. 56–70.

[11] R. Pucella and J. A. Tov, “Haskell session types with (almost) noclass,” SIGPLAN Not., vol. 44, no. 2, pp. 25–36, Sep. 2008. [Online].Available: http://doi.acm.org/10.1145/1543134.1411290

[12] M. Sackman and S. Eisenbach, “Session Types in Haskell: UpdatingMessage Passing for the 21st Century,” Tech. Rep., June 2008.[Online]. Available: http://pubs.doc.ic.ac.uk/session-types-in-haskell/

[13] L. G. Mezzina, “How to infer finite session types in a calculus of servi-ces and sessions,” in Proceedings of the 10th international conferenceon Coordination models and languages, ser. COORDINATION’08.Berlin, Heidelberg: Springer-Verlag, 2008, pp. 216–231. [Online].Available: http://dl.acm.org/citation.cfm?id=1788954.1788968

[14] K. Imai, S. Yuen, and K. Agusa, “Session type inference in haskell,” inPLACES, ser. EPTCS, K. Honda and A. Mycroft, Eds., vol. 69, 2010,pp. 74–91.

[15] P. Collingbourne and P. H. J. Kelly, “Inference of sessiontypes from control flow,” Electron. Notes Theor. Comput. Sci.,vol. 238, no. 6, pp. 15–40, Jun. 2010. [Online]. Available:http://dx.doi.org/10.1016/j.entcs.2010.06.003

[16] M. P. Jones, “Type classes with functional dependencies,” inProceedings of the 9th European Symposium on ProgrammingLanguages and Systems, ser. ESOP ’00. London, UK, UK:Springer-Verlag, 2000, pp. 230–244. [Online]. Available: http://dl.acm.org/citation.cfm?id=645394.651909

[17] A. Tasistro, E. Copello, and N. Szasz, “Principal type scheme forsession types,” International Journal of Logic and Computation( IJLP ), vol. 3, pp. 34–43, December 2012. [Online].Available: http://www.cscjournals.org/csc/manuscriptinfo.php?ManuscriptCode=70.71.73.77.42.47.51.101&JCode=IJLP&EJCode=64.65.67.71.107&Volume=3&Issue=1

[18] E. Copello, “Inferencia de tipos de tipos de sesion,” Febrero 2012, Tesisde Maestrıa, Facultad de Ingenierıa, Universidad ORT Uruguay.

[19] K. Takeuchi, K. Honda, and M. Kubo, “An interaction-based languageand its typing system,” in PARLE, ser. Lecture Notes in Computer Scien-ce, C. Halatsis, D. G. Maritsas, G. Philokyprou, and S. Theodoridis,Eds., vol. 817. Springer, 1994, pp. 398–413.

[20] N. Yoshida and V. T. Vasconcelos, “Language primitives andtype discipline for structured communication-based programmingrevisited: Two systems for higher-order session communication,”

in 1st International Workshop on Security and RewritingTechniques, ser. ENTCS, vol. 171(4). Elsevier, 2007, pp. 73–93. [Online]. Available: http://www.di.fc.ul.pt/∼vv/papers/yoshida.vasconcelos:language-primitives-revisited.pdf

[21] V. T. Vasconcelos, M. Giunti, N. Yoshida, and K. Honda,“Type safety without subject reduction for session types,” 2010.[Online]. Available: http://www.di.fc.ul.pt/∼vv/papers/vasconcelos.giunti.etal type-safety-session-types.pdf

[22] S. J. Gay and M. Hole, “Subtyping for session types in the pi calculus.”Acta Inf., pp. 191–225, 2005.

[23] A. Igarashi and N. Kobayashi, “A generic type system for thepi-calculus,” Theor. Comput. Sci., vol. 311, no. 1-3, pp. 121–163, Jan.2004. [Online]. Available: http://dx.doi.org/10.1016/S0304-3975(03)00325-6

[24] N. Kobayashi, B. C. Pierce, and D. N. Turner, “Linearity and the pi-calculus,” 1999.

[25] V. T. Vasconcelos and K. Honda, “Principal typing schemes in apolyadic π-calculus,” in CONCUR’93, LNCS 715. Springer-Verlag,1993, pp. 524–538.

[26] H. B. Curry, Combinatory logic / [by] Haskell B. Curry [and] RobertFeys. With two sections by William Craig. North-Holland Pub. Co.,Amsterdam, 1958.

[27] C. Dubois and V. Menissier-Morain, “Certification of a type inferencetool for ml: Damas-milner within coq,” Journal of Automated Reaso-ning, vol. 23, pp. 3–4, 1999.

[28] L. Bettini, M. Coppo, L. D’Antoni, M. De Luca, M. Dezani-Ciancaglini, and N. Yoshida, “Global Progress in DynamicallyInterleaved Multiparty Sessions,” in Proc. of Concur, ser. LNCS,vol. 5201. Springer, 2008, pp. 418–433. [Online]. Available:http://rap.dsi.unifi.it/phpbibliography/files/global progress.pdf

[29] L. G. Mezzina, “How to infer finite session types in a calculus of servi-ces and sessions,” in Proceedings of the 10th international conferenceon Coordination models and languages, ser. COORDINATION’08.Berlin, Heidelberg: Springer-Verlag, 2008, pp. 216–231. [Online].Available: http://dl.acm.org/citation.cfm?id=1788954.1788968

[30] J. A. Robinson, “Logic and logic programming,” Commun. ACM,vol. 35, no. 3, pp. 40–65, 1992.

http://www.di.fc.ul.pt/~vv/papers/honda.vasconcelos.kubo_language-primitives.pdf

http://www.di.fc.ul.pt/~vv/papers/honda.vasconcelos.kubo_language-primitives.pdf

http://doi.acm.org/10.1145/1543134.1411290

http://pubs.doc.ic.ac.uk/session-types-in-haskell/

http://dl.acm.org/citation.cfm?id=1788954.1788968

http://dx.doi.org/10.1016/j.entcs.2010.06.003



http://www.cscjournals.org/csc/manuscriptinfo.php?ManuscriptCode=70.71.73.77.42.47.51.101&JCode=IJLP&EJCode=64.65.67.71.107&Volume=3&Issue=1



http://www.di.fc.ul.pt/~vv/papers/yoshida.vasconcelos:language-primitives-revisited.pdf

http://www.di.fc.ul.pt/~vv/papers/yoshida.vasconcelos:language-primitives-revisited.pdf

http://www.di.fc.ul.pt/~vv/papers/vasconcelos.giunti.etal_type-safety-session-types.pdf

http://www.di.fc.ul.pt/~vv/papers/vasconcelos.giunti.etal_type-safety-session-types.pdf

http://dx.doi.org/10.1016/S0304-3975(03)00325-6

http://dx.doi.org/10.1016/S0304-3975(03)00325-6

http://rap.dsi.unifi.it/phpbibliography/files/global_progress.pdf


inferencia de tipos de sesión · resumen—el c´alculo de tipos de sesi ´on tal como es...

Documents