Domanda

Ho letto che l'inferenza dei tipi di Scala non è così globale che è il motivo per cui le persone devono posizionare le annotazioni di tipo sui metodi. (Questo sarebbe "locale" inferenza di tipo?)

Ho solo un po 'di capire che la ragione è dalla sua natura orientata agli oggetti, ma chiarezza mi sfugge. C'è una spiegazione per "inferenza di tipo globale" e perché Scala non può avere che un principiante potrebbe capire?

È stato utile?

Soluzione

L'esempio tipico per un tipo di inferenza globale è Hindley-Milner : Ci vuole dato programma e "calcola" tutti i tipi necessari. Tuttavia, al fine di raggiungere questo obiettivo, il linguaggio data ha bisogno di avere alcune proprietà (ci sono le estensioni per HM, che cercano di superare alcune di queste restrizioni). Due cose HM non piace sono eredità e overloading dei metodi. Per quanto ho capito questi sono i principali ostacoli per Scala ad adottare HM o qualche variante di esso. Si noti che nella pratica, anche lingue che pesantemente si basano su HM non raggiungono mai una deduzione al 100%, ad esempio, anche in Haskell è necessario un tipo di annotazione di tanto in tanto.

Quindi, Scala usa un più limitato (come dici tu "locale") sotto forma di inferenza dei tipi, che è ancora meglio di niente. Per quanto posso dire la squadra Scala cerca di migliorare il tipo di inferenza da una release all'altra, quando è possibile, ma finora ho visto solo passi più piccoli. Il divario a un tipo inferencer stile HM è ancora enorme, e non può essere chiuso completamente.

Altri suggerimenti

Il problema è che tipo HM inferenza è indecidibile, in generale, in una lingua con sottotipizzazione, sovraccarico o caratteristiche simili. Ref questo significa più e più roba potrebbe essere aggiunto al inferencer per renderlo dedurre casi più particolari, ma ci saranno sempre codice in cui fallirà.

Scala ha preso la decisione di fare annotazioni di tipo di argomenti di metodo e alcuni altri luoghi obbligatori. Questo potrebbe sembrare una seccatura prima, ma considerare che questo aiuta a documentare il codice e fornisce il compilatore con informazioni che può comprendere in un unico luogo. Inoltre, le lingue con HM inferenza spesso soffrono il problema che gli errori di programmazione a volte sono rilevati nel codice lontano dal l'errore originale, perché l'algoritmo di HM appena andato avanti e successo (per caso) di inferire altre parti del codice con il tipo di guasto essa ha dedotto prima che non è riuscita.

inferenza di Scala fondamentalmente funziona dall'esterno (definizione di un metodo) verso l'interno (codice all'interno del metodo) e limita quindi l'impatto di un tipo di annotazione sbagliata.

Lingue con HM lavoro inferenza dall'interno verso l'esterno (ignorando la possibilità di aggiungere annotazioni di tipo), che significa che c'è una possibilità che una piccola modifica del codice in un unico metodo può cambiare il senso di tutto il programma. Questo può essere buono o cattivo.


Rif: Lower bounds on type inference with subtypes

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top