¿Hay alguna razón para tener un tipo de fondo en un lenguaje de programación?

Un tipo de fondo es una construcción que aparece principalmente en la teoría de tipos matemáticos. También se llama el tipo vacío. Es un tipo que no tiene valores, pero es un subtipo de todos los tipos.

Si el tipo de retorno de una función es el tipo inferior, eso significa que no regresa. Período. Tal vez se repita para siempre, o tal vez arroje una excepción.

¿Cuál es el punto de tener este tipo extraño en un lenguaje de programación? No es tan común, pero está presente en algunos, como Scala y Lisp.

Tomaré un ejemplo simple: C ++ vs Rust.

Aquí hay una función utilizada para lanzar una excepción en C ++ 11:

[[noreturn]] void ThrowException(char const* message,
                                 char const* file,
                                 int line,
                                 char const* function);

Y aquí está el equivalente en Rust:

fn formatted_panic(message: &str, file: &str, line: isize, function: &str) -> !;

En un asunto puramente sintáctico, la construcción Rust es más sensata. Tenga en cuenta que la construcción C ++ especifica un tipo de retorno , aunque también especifica que no va a volver. Eso es un poco raro.

En una nota estándar, la sintaxis de C ++ solo apareció con C ++ 11 (se agregó en la parte superior), pero varios compiladores habían estado proporcionando varias extensiones durante un tiempo, por lo que las herramientas de análisis de terceros tuvieron que programarse para reconocer las diversas formas Este atributo podría ser escrito. Tenerlo estandarizado es obviamente claramente superior.

Ahora, en cuanto al beneficio?

El hecho de que una función no regrese puede ser útil para:

• optimización: se puede podar cualquier código después (no volverá), no es necesario guardar los registros (ya que no será necesario restaurarlos), ...
• análisis estático: elimina una serie de posibles rutas de ejecución
• mantenibilidad: (ver análisis estático, pero por humanos)

La respuesta de Karl es buena. Aquí hay un uso adicional que no creo que nadie más haya mencionado. El tipo de

if E then A else B

debe ser un tipo que incluya todos los valores en el tipo de Ay todos los valores en el tipo de B. Si el tipo de Bes Nothing, entonces el tipo de la ifexpresión puede ser el tipo de A. A menudo declaro una rutina

def unreachable( s:String ) : Nothing = throw new AssertionError("Unreachable "+s) 

decir que no se espera alcanzar el código. Dado que su tipo es Nothing, unreachable(s)ahora se puede usar en cualquiera ifo (más a menudo) switchsin afectar el tipo de resultado. Por ejemplo

 val colour : Colour := switch state of
         BLACK_TO_MOVE: BLACK
         WHITE_TO_MOVE: WHITE
         default: unreachable("Bad state")

Scala tiene ese tipo de Nada.

Otro caso de uso para Nothing(como se menciona en la respuesta de Karl) es Lista [Nada] es el tipo de listas de cada uno de cuyos miembros tiene el tipo Nada. Por lo tanto, puede ser el tipo de la lista vacía.

La propiedad clave de Nothingesto hace que estos casos de uso funcionen no es que no tenga valores, aunque en Scala, por ejemplo, no tiene valores, es que es un subtipo de cualquier otro tipo.

Supongamos que tiene un idioma donde cada tipo contiene el mismo valor, llamémoslo (). En dicho lenguaje, el tipo de unidad, que tiene ()como único valor, podría ser un subtipo de cada tipo. Eso no lo convierte en un tipo inferior en el sentido que significaba el OP; el OP dejó claro que un tipo de fondo no contiene valores. Sin embargo, como es un tipo que es un subtipo de cada tipo, puede desempeñar el mismo papel que un tipo inferior.

Haskell hace las cosas un poco diferente. En Haskell, una expresión que nunca produce un valor puede tener el esquema de tipo forall a.a. Una instancia de este esquema de tipo se unificará con cualquier otro tipo, por lo que efectivamente actúa como un tipo de fondo, aunque Haskell (estándar) no tiene noción de subtipo. Por ejemplo, la errorfunción del preludio estándar tiene un esquema de tipo forall a. [Char] -> a. Entonces puedes escribir

if E then A else error ""

y el tipo de expresión será el mismo que el tipo de A, para cualquier expresión A.

La lista vacía en Haskell tiene el esquema de tipo forall a. [a]. Si Aes una expresión cuyo tipo es un tipo de lista, entonces

if E then A else []

es una expresión con el mismo tipo que A.

Los tipos forman un monoide de dos maneras, juntos haciendo un semired . Eso es lo que se llama tipos de datos algebraicos . Para los tipos finitos, este semiring se relaciona directamente con el semired de los números naturales (incluido el cero), lo que significa que cuenta cuántos valores posibles tiene el tipo (excluyendo los "valores no determinantes").

• El tipo inferior (lo llamaré Vacuous) tiene valores cero ^† .
• El tipo de unidad tiene un valor. Llamaré tanto al tipo como a su valor único ().
• La composición (que la mayoría de los lenguajes de programación admite de forma bastante directa, a través de registros / estructuras / clases con campos públicos) es una operación del producto . Por ejemplo, (Bool, Bool)tiene cuatro valores posibles, a saber (False,False), (False,True), (True,False)y (True,True).
  El tipo de unidad es el elemento de identidad de la operación de composición. Por ejemplo, ((), False)y ((), True)son los únicos valores de tipo ((), Bool), por lo que este tipo es isomorfo a Boolsí mismo.
• Los tipos alternativos son algo descuidados en la mayoría de los idiomas (los idiomas OO los apoyan con herencia), pero no son menos útiles. Una alternativa entre dos tipos Ay Bbásicamente tiene todos los valores de A, además de todos los valores de B, por lo tanto, el tipo de suma . Por ejemplo, Either () Booltiene tres valores, voy a llamarlos Left (), Right Falsey Right True.
  El tipo inferior es el elemento de identidad de la suma: soloEither Vacuous A tiene valores de la forma , porque no tiene sentido ( no tiene valores).Right aLeft ...Vacuous

Lo interesante de estos monoides es que, cuando introduce funciones en su idioma, la categoría de estos tipos con las funciones de morfismos es una categoría monoidal . Entre otras cosas, esto le permite definir functores y mónadas aplicativos , que resultan ser una excelente abstracción para los cálculos generales (posiblemente con efectos secundarios, etc.) en términos puramente funcionales.

Ahora, en realidad puede llegar bastante lejos si se preocupa solo por un lado del problema (el monoide de composición), entonces realmente no necesita el tipo de fondo explícitamente. Por ejemplo, incluso Haskell no tuvo durante mucho tiempo un tipo de fondo estándar. Ahora sí, se llama Void.

Pero cuando considera la imagen completa, como una categoría cerrada bicartesiana , el sistema de tipos es realmente equivalente a todo el cálculo lambda, por lo que básicamente tiene la abstracción perfecta sobre todo lo posible en un lenguaje completo de Turing. Ideal para lenguajes integrados específicos de dominio, por ejemplo, hay un proyecto sobre codificar directamente circuitos electrónicos de esta manera .

Por supuesto, bien puedes decir que esto es una tontería general de todos los teóricos . No es necesario que conozca la teoría de categorías para ser un buen programador, pero cuando lo hace, le brinda formas poderosas y ridículamente generales de razonar sobre el código y probar invariantes.

^† _{mb21 me recuerda que tenga en cuenta que esto no debe confundirse con los valores inferiores . En lenguajes perezosos como Haskell, cada tipo contiene un "valor" inferior, denotado ⊥. Esto no es algo concreto que puedas pasar explícitamente, sino que es lo que se "devuelve", por ejemplo, cuando una función se repite para siempre. Incluso el Voidtipo de Haskell "contiene" el valor inferior, de ahí el nombre. Desde ese punto de vista, el tipo de fondo de Haskell realmente tiene un valor y su tipo de unidad tiene dos valores, pero en la discusión de teoría de categorías esto generalmente se ignora.}

Tal vez se repita para siempre, o tal vez arroje una excepción.

Suena como un tipo útil para tener en esas situaciones, aunque sean raros.

Además, aunque Nothing(el nombre de Scala para el tipo inferior) no puede tener valores, List[Nothing]no tiene esa restricción, lo que lo hace útil como el tipo de una lista vacía. La mayoría de los idiomas resuelven esto haciendo una lista vacía de cadenas de un tipo diferente que una lista vacía de enteros, lo que tiene sentido, pero hace que una lista vacía sea más detallada para escribir, lo cual es un gran inconveniente en un lenguaje orientado a listas.

Es útil para el análisis estático documentar el hecho de que una ruta de código particular no es accesible. Por ejemplo, si escribe lo siguiente en C #:

int F(int arg) {
 if (arg != 0)
  return arg + 1; //some computation
 else
  Assert(false); //this throws but the compiler does not know that
}
void Assert(bool cond) { if (!cond) throw ...; }

El compilador se quejará de que Fno devuelve nada en al menos una ruta de código. Si Assertse marcara como no devuelto, el compilador no necesitaría avisar.

En algunos idiomas, nulltiene el tipo inferior, ya que el subtipo de todos los tipos define muy bien para qué lenguajes usan nulo (a pesar de la leve contradicción de nullser ambos mismos y una función que se devuelve, evitando los argumentos comunes sobre por qué botdebería estar deshabitada).

También se puede usar como una función general en los tipos de función ( any -> bot) para manejar el envío que salió mal.

Y algunos idiomas le permiten resolverlo realmente botcomo un error, que puede usarse para proporcionar errores de compilación personalizados.

Sí, este es un tipo bastante útil; Si bien su función sería principalmente interior al sistema de tipos, hay algunas ocasiones en las que el tipo de fondo aparecería abiertamente.

Considere un lenguaje de tipo estático en el que los condicionales son expresiones (por lo que la construcción if-then-else se duplica como el operador ternario de C y amigos, y puede haber una declaración de caso de múltiples vías similar). El lenguaje de programación funcional tiene esto, pero también ocurre en ciertos lenguajes imperativos (desde ALGOL 60). Entonces, todas las expresiones de rama deben producir finalmente el tipo de la expresión condicional completa. Uno podría simplemente requerir que sus tipos sean iguales (y creo que este es el caso del operador ternario en C), pero esto es demasiado restrictivo, especialmente cuando el condicional también se puede usar como enunciado condicional (sin devolver ningún valor útil). En general, se quiere que cada expresión de rama sea (implícitamente) convertible a un tipo común que será el tipo de la expresión completa (posiblemente con restricciones más o menos complicadas para permitir que el compilador encuentre efectivamente ese tipo común, cf. C ++, pero no entraré en esos detalles aquí).

Hay dos tipos de situaciones en las que un tipo general de conversión permitirá la flexibilidad necesaria de tales expresiones condicionales. Ya se mencionó uno, donde el tipo de resultado es el tipo de unidadvoid; Esto es naturalmente un supertipo de todos los otros tipos, y permitir que cualquier tipo se convierta (trivialmente) en él hace posible usar la expresión condicional como declaración condicional. El otro involucra casos en los que la expresión devuelve un valor útil, pero una o más ramas son incapaces de producir uno. Por lo general, plantearán una excepción o implicarán un salto, y requerirles que (también) produzcan un valor del tipo de la expresión completa (desde un punto inalcanzable) no tendría sentido. Es este tipo de situación la que se puede manejar con gracia al dar cláusulas, saltos y llamadas de aumento de excepciones que tendrán ese efecto, el tipo inferior, el único tipo que puede convertirse (trivialmente) en cualquier otro tipo.

Sugeriría escribir un tipo inferior *para sugerir su convertibilidad a tipo arbitrario. Puede tener otros propósitos útiles internamente, por ejemplo, cuando se intenta deducir un tipo de resultado para una función recursiva que no declara ninguno, el inferenciador de tipo podría asignar el tipo *a cualquier llamada recursiva para evitar una situación de gallina y huevo; el tipo real estará determinado por ramas no recursivas, y las recursivas se convertirán al tipo común de las no recursivas. Si no hay ramas no recursivas, el tipo permanecerá *e indicará correctamente que la función no tiene forma alguna de regresar de la recursividad. Aparte de esto y como resultado de las funciones de lanzamiento de excepciones, se puede usar*como tipo de componente de secuencias de longitud 0, por ejemplo de la lista vacía; nuevamente, si alguna vez se selecciona un elemento de una expresión de tipo [*](lista necesariamente vacía), el tipo resultante *indicará correctamente que esto nunca puede regresar sin un error.

En algunos idiomas, puede anotar una función para decirle tanto al compilador como a los desarrolladores que una llamada a esta función no se devolverá (y si la función está escrita de una manera que pueda regresar, el compilador no lo permitirá ) Es algo útil de saber, pero al final puede llamar a una función como esta como cualquier otra. El compilador puede usar la información para la optimización, para dar advertencias sobre el código muerto, etc. Por lo tanto, no hay una razón muy convincente para tener este tipo, pero tampoco hay una razón muy convincente para evitarlo.

En muchos idiomas, una función puede devolver "void". Lo que eso significa exactamente depende del idioma. En C significa que la función no devuelve nada. En Swift, significa que la función devuelve un objeto con un solo valor posible, y dado que solo hay un valor posible, ese valor toma cero bits y en realidad no requiere ningún código. En cualquier caso, eso no es lo mismo que "fondo".

"bottom" sería un tipo sin valores posibles. Nunca puede existir. Si una función devuelve "bottom", en realidad no puede regresar, porque no hay ningún valor de tipo "bottom" que pueda devolver.

Si un diseñador de idiomas lo desea, entonces no hay razón para no tener ese tipo. La implementación no es difícil (puede implementarla exactamente como una función que devuelve nula y marcada como "no regresa"). No puede mezclar punteros a funciones que regresan al fondo con punteros a funciones que devuelven vacío, porque no son del mismo tipo).