C'è un motivo per avere un tipo di fondo in un linguaggio di programmazione?

Un tipo di fondo è un costrutto che appare principalmente nella teoria dei tipi matematica. Si chiama anche il tipo vuoto. È un tipo che non ha valori, ma è un sottotipo di tutti i tipi.

Se il tipo restituito di una funzione è il tipo inferiore, significa che non restituisce. Periodo. Forse gira per sempre, o forse genera un'eccezione.

Qual è il punto di avere questo strano tipo in un linguaggio di programmazione? Non è così comune, ma è presente in alcuni, come Scala e Lisp.

Prenderò un semplice esempio: C ++ vs Rust.

Ecco una funzione utilizzata per generare un'eccezione in C ++ 11:

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

Ed ecco l'equivalente in Rust:

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

Su una questione puramente sintattica, il costrutto Rust è più sensato. Si noti che il costrutto C ++ specifica un tipo restituito anche se specifica anche che non restituirà. È un po 'strano.

Su una nota standard, la sintassi C ++ è apparsa solo con C ++ 11 (era trattata in cima), ma vari compilatori avevano fornito varie estensioni per un po ', quindi gli strumenti di analisi di terze parti dovevano essere programmati per riconoscere i vari modi questo attributo potrebbe essere scritto. Avere standardizzato è ovviamente chiaramente superiore.

Ora, per quanto riguarda il vantaggio?

Il fatto che una funzione non ritorni può essere utile per:

• ottimizzazione: è possibile eliminare qualsiasi codice dopo di esso (non restituirà), non è necessario salvare i registri (in quanto non sarà necessario ripristinarli), ...
• analisi statica: elimina una serie di potenziali percorsi di esecuzione
• manutenibilità: (vedi analisi statica, ma da parte dell'uomo)

La risposta di Karl è buona. Ecco un ulteriore uso che non penso che sia stato menzionato da nessun altro. Il tipo di

if E then A else B

dovrebbe essere un tipo che include tutti i valori nel tipo di Ae tutti i valori nel tipo di B. Se il tipo di Bè Nothing, il tipo ifdell'espressione può essere il tipo di A. Dichiarerò spesso una routine

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

per dire che il codice non dovrebbe essere raggiunto. Dal momento che il suo tipo è Nothing, unreachable(s)ora può essere utilizzato in qualsiasi ifo (più spesso) switchsenza influire sul tipo di risultato. Per esempio

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

Scala ha un tale tipo di niente.

Un altro caso d'uso per Nothing(come menzionato nella risposta di Karl) è Elenco [Niente] è il tipo di elenchi ciascuno dei cui membri ha il tipo Nulla. Quindi può essere il tipo di elenco vuoto.

La proprietà chiave Nothingche fa funzionare questi casi d'uso non è che non abbia valori - sebbene in Scala, ad esempio, non abbia valori - è che è un sottotipo di ogni altro tipo.

Supponiamo di avere una lingua in cui ogni tipo contiene lo stesso valore: chiamiamolo (). In tale linguaggio il tipo di unità, che ha ()come unico valore, potrebbe essere un sottotipo di ogni tipo. Ciò non lo rende un tipo di fondo, nel senso che significava OP; l'OP era chiaro che un tipo di fondo non contiene valori. Tuttavia, poiché è un tipo che è un sottotipo di ogni tipo, può svolgere lo stesso ruolo di un tipo di fondo.

Haskell fa le cose in modo leggermente diverso. In Haskell, un'espressione che non produce mai un valore può avere lo schema dei tipi forall a.a. Un'istanza di questo schema di tipi si unificherà con qualsiasi altro tipo, quindi agisce efficacemente come tipo di fondo, anche se (standard) Haskell non ha alcuna nozione di sottotipo. Ad esempio, la errorfunzione del preludio standard ha uno schema di tipi forall a. [Char] -> a. Quindi puoi scrivere

if E then A else error ""

e il tipo di espressione sarà lo stesso del tipo di A, per qualsiasi espressione A.

L'elenco vuoto in Haskell ha lo schema dei tipi forall a. [a]. If Aè un'espressione il cui tipo è un tipo di elenco, quindi

if E then A else []

è un'espressione con lo stesso tipo di A.

I tipi formano un monoide in due modi, facendo insieme un semiring . Questo è ciò che si chiama tipi di dati algebrici . Per i tipi finiti, questo semiring si riferisce direttamente al semina di numeri naturali (incluso zero), il che significa che si contano quanti possibili valori ha il tipo (esclusi i "valori non terminanti").

• Il tipo in basso (lo chiamerò Vacuous) ha zero valori ^† .
• Il tipo di unità ha un valore. Chiamerò sia il tipo che il suo valore singolo ().
• La composizione (che la maggior parte dei linguaggi di programmazione supporta abbastanza direttamente, attraverso record / strutture / classi con campi pubblici) è un'operazione del prodotto . Per esempio, (Bool, Bool)ha quattro valori possibili, vale a dire (False,False), (False,True), (True,False)e (True,True).
  Il tipo di unità è l'elemento di identità dell'operazione di composizione. Ad esempio ((), False)e ((), True)sono gli unici valori di tipo ((), Bool), quindi questo tipo è isomorfo a Boolse stesso.
• I tipi alternativi sono in qualche modo trascurati nella maggior parte delle lingue (le lingue OO le supportano con eredità), ma non sono meno utili. Un'alternativa tra due tipi Ae Bsostanzialmente ha tutti i valori di A, oltre a tutti i valori di B, quindi il tipo di somma . Per esempio, Either () Boolha tre valori, li chiamerò Left (), Right Falsee Right True.
  Il tipo in basso è l'elemento identità della somma: Either Vacuous Aha solo valori del modulo Right a, perché Left ...non ha senso ( Vacuousnon ha valori).

La cosa interessante di questi monoidi è che, quando introduci funzioni nella tua lingua, la categoria di questi tipi con le funzioni come morfismi è una categoria monoidale . Tra le altre cose, ciò consente di definire funzioni e monadi applicative , che si rivelano un'ottima astrazione per calcoli generali (che possono comportare effetti collaterali, ecc.) In termini altrimenti puramente funzionali.

Ora, in realtà puoi andare abbastanza lontano preoccupandoti solo di una parte del problema (la composizione monoidale), quindi non hai davvero bisogno del tipo di fondo esplicitamente. Ad esempio, anche Haskell per lungo tempo non aveva un tipo di fondo standard. Ora ha, si chiama Void.

Ma quando consideri il quadro completo, come una categoria chiusa bicartesiana , allora il sistema di tipi è in realtà equivalente all'intero calcolo lambda, quindi in pratica hai l'astrazione perfetta su tutto il possibile in un linguaggio completo di Turing. Ottimo per linguaggi specifici del dominio incorporato, ad esempio esiste un progetto sulla codifica diretta dei circuiti elettronici in questo modo .

Certo, potresti ben dire che questa è una sciocchezza generale di tutti i teorici . Non è necessario conoscere la teoria delle categorie per essere un buon programmatore, ma quando lo fai, ti dà modi potenti e ridicolmente generali di ragionare sul codice e di creare invarianti.

^† _{mb21 mi ricorda di notare che ciò non deve essere confuso con i valori inferiori . In lingue pigre come Haskell, ogni tipo contiene un "valore" inferiore, indicato ⊥. Questa non è una cosa concreta che potresti mai esplicitamente passare, ma è ciò che è "restituito", ad esempio quando una funzione scorre per sempre. Anche il Voidtipo di Haskell "contiene" il valore inferiore, quindi il nome. Alla luce di ciò, il tipo di fondo di Haskell ha davvero un valore e il suo tipo di unità ha due valori, ma nella discussione sulla teoria delle categorie questo è generalmente ignorato.}

Forse gira per sempre, o forse genera un'eccezione.

Sembra un tipo utile da avere in quelle situazioni, per quanto rare possano essere.

Inoltre, anche se Nothing(il nome di Scala per il tipo in basso) non può avere valori, List[Nothing]non ha quella restrizione, che lo rende utile come il tipo di un elenco vuoto. La maggior parte delle lingue aggira questo creando un elenco vuoto di stringhe di tipo diverso rispetto a un elenco vuoto di numeri interi, il che ha un senso, ma rende un elenco vuoto più prolisso da scrivere, il che è un grosso svantaggio in un linguaggio orientato all'elenco.

È utile per l'analisi statica documentare il fatto che un determinato percorso di codice non è raggiungibile. Ad esempio se si scrive quanto segue in 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 ...; }

Il compilatore si lamenterà che Fnon restituisce nulla in almeno un percorso di codice. Se Assertdovesse essere contrassegnato come non restituito, il compilatore non avrebbe bisogno di avvisare.

In alcune lingue, nullha il tipo di fondo, dal momento che il sottotipo di tutti i tipi definisce bene per quali lingue si usa null (nonostante la lieve contraddizione di nullessere sia se stesso che una funzione che ritorna se stessa, evitando gli argomenti comuni sul perché botdovrebbero essere disabitati).

Può anche essere utilizzato come catch-all nei tipi di funzione ( any -> bot) per gestire la spedizione andata male.

E alcune lingue ti consentono di risolvere effettivamente botcome un errore, che può essere utilizzato per fornire errori del compilatore personalizzati.

Sì, questo è un tipo abbastanza utile; mentre il suo ruolo sarebbe principalmente interno al sistema di tipi, ci sono alcune occasioni in cui il tipo di fondo appare apertamente.

Prendi in considerazione un linguaggio tipicamente statico in cui i condizionali sono espressioni (quindi la costruzione if-then-else raddoppia come operatore ternario di C e amici, e potrebbe esserci un'affermazione a caso multipla simile). Il linguaggio di programmazione funzionale ha questo, ma succede anche in alcuni linguaggi imperativi (sin da ALGOL 60). Quindi tutte le espressioni di ramo devono in definitiva produrre il tipo dell'intera espressione condizionale. Si potrebbe semplicemente richiedere che i loro tipi siano uguali (e penso che questo sia il caso dell'operatore ternario in C), ma ciò è eccessivamente restrittivo, specialmente quando il condizionale può anche essere usato come istruzione condizionale (non restituendo alcun valore utile). In generale si vuole che ogni espressione di ramo sia (implicitamente) convertibile a un tipo comune che sarà il tipo dell'espressione completa (possibilmente con restrizioni più o meno complicate per consentire a quel tipo comune di essere efficacemente trovato dal complier, cfr. C ++, ma non entrerò in quei dettagli qui).

Esistono due tipi di situazioni in cui un tipo generale di conversione consentirà la necessaria flessibilità di tali espressioni condizionali. Uno è già menzionato, in cui il tipo di risultato è il tipo di unitàvoid; questo è naturalmente un super-tipo di tutti gli altri tipi e consentire a qualsiasi tipo di essere (banalmente) convertito in esso rende possibile usare l'espressione condizionale come istruzione condizionale. L'altro riguarda casi in cui l'espressione restituisce un valore utile, ma uno o più rami non sono in grado di produrne uno. Solitamente solleveranno un'eccezione o comporteranno un salto e richiedere loro di (anche) produrre un valore del tipo dell'intera espressione (da un punto irraggiungibile) sarebbe inutile. È questo tipo di situazione che può essere gestita con garbo dando clausole, salti e chiamate che generano eccezioni che avranno un tale effetto, il tipo in basso, l'unico tipo che può essere (banalmente) convertito in qualsiasi altro tipo.

Suggerirei di scrivere un tipo così basso da *suggerire la sua convertibilità in tipo arbitrario. Può servire internamente ad altri scopi utili, ad esempio quando si cerca di dedurre un tipo di risultato per una funzione ricorsiva che non ne dichiara alcuna, l'inferenziatore del tipo potrebbe assegnare il tipo *a qualsiasi chiamata ricorsiva per evitare una situazione di gallina e uovo; il tipo effettivo sarà determinato da rami non ricorsivi e quelli ricorsivi saranno convertiti nel tipo comune di rami non ricorsivi. Se ci sono presenti rami non ricorsivi affatto, il tipo rimarrà *, e indicano correttamente che la funzione ha alcun modo possibile di mai ritorno dal ricorsione. Oltre a questo e come tipo di risultato delle funzioni di lancio delle eccezioni, si può usare*come tipo di componente di sequenze di lunghezza 0, ad esempio dell'elenco vuoto; di nuovo se mai un elemento viene selezionato da un'espressione di tipo [*](necessariamente elenco vuoto), il tipo risultante *indicherà correttamente che questo non può mai tornare senza un errore.

In alcune lingue, è possibile annotare una funzione per dire sia al compilatore che agli sviluppatori che non verrà restituita una chiamata a questa funzione (e se la funzione è scritta in modo da poter essere restituita, il compilatore non lo consentirà ). Questa è una cosa utile da sapere, ma alla fine puoi chiamare una funzione come questa come qualsiasi altra. Il compilatore può utilizzare le informazioni per l'ottimizzazione, per fornire avvisi sul codice morto e così via. Quindi non esiste un motivo molto convincente per avere questo tipo, ma neppure un motivo molto convincente per evitarlo.

In molte lingue, una funzione può restituire "nulla". Cosa significa esattamente dipende dalla lingua. In C significa che la funzione non restituisce nulla. In Swift, significa che la funzione restituisce un oggetto con un solo valore possibile e poiché esiste un solo valore possibile, quel valore accetta zero bit e in realtà non richiede alcun codice. In entrambi i casi, non è lo stesso di "bottom".

"bottom" sarebbe un tipo senza valori possibili. Non può mai esistere. Se una funzione restituisce "bottom", in realtà non può tornare, perché non può restituire alcun valore di tipo "bottom".

Se un designer linguistico ne ha voglia, allora non c'è motivo di non avere quel tipo. L'implementazione non è difficile (puoi implementarla esattamente come una funzione che restituisce nulla e contrassegnata come "non restituisce"). Non è possibile mescolare i puntatori a funzioni che ritornano in basso con i puntatori a funzioni che restituiscono nulla, perché non sono dello stesso tipo).