Sfondo
In una lingua come F #, è possibile l'interoperabilità diretta con la maggior parte degli altri linguaggi .NET. Ad esempio, è possibile utilizzare le classi scritte in C # direttamente in F #, ed è possibile chiamare il codice F # direttamente da C #.
In F #, i moduli vengono compilati in istruzioni CIL corrispondenti a classi statiche, ADT a una gerarchia di classi (classe astratta + sottoclassi) e così via. Ciò semplifica l'interoperabilità, ma pone alcune limitazioni sulle funzionalità linguistiche.
Ad esempio, F # non supporta i moduli di ordine superiore come OCaml e SML (o un meccanismo "simile" come i typeclass o simili). Se questo è cruciale o no è soggettivo, ma limita le opzioni per scrivere codice polimorfico (senza usare le parti OO del linguaggio).
Interoperabilità attraverso alcune interfacce
Naturalmente, un'alternativa non ignora i problemi di interoperabilità nella parte principale del linguaggio e crea un'interfaccia specifica per l'interoperabilità. Questo potrebbe essere a senso unico o bidirezionale.
Ad esempio, in una lingua come F #, un progetto alternativo avrebbe potuto essere qualcosa di simile:
- Lascia che F # usi direttamente le classi C #, come oggi. In questo modo, usare le librerie .NET è ancora facile.
- Ignora la capacità di C # di accedere direttamente al codice F # funzionale. Ciò eliminerebbe alcune limitazioni attualmente imposte al design del linguaggio: potremmo in questo modo supportare facilmente un sistema di tipi più strong, con moduli di ordine superiore o typeclass, ecc.
- Lascia che C # acceda direttamente alle parti OO di F #. Quindi, se vuoi che le nostre librerie F # siano accessibili da C #, dovremmo inserirle in un sottile wrapper OO.
In alcuni casi ciò richiederebbe un po 'più di lavoro, ma nella mia esperienza probabilmente mi aspetterei che la maggior parte delle persone progetterebbe comunque un wrapper OO, se una libreria F # deve essere utilizzata in C #.
Nel caso in cui una libreria F # non abbia un wrapper OO, sarebbe comunque possibile crearne una da solo (in F # ovviamente).
Nel caso più estremo, questa interfaccia potrebbe essere bidirezionale, in modo tale che F # possa solo accedere alle classi .NET attraverso alcune interfacce pure - ma ci sarebbero probabilmente poche ragioni per imporre tale restrizione in questo caso. Ma per altri linguaggi potrebbe essere un'opzione - se ad esempio volessi scrivere un linguaggio puro o qualcosa del genere.
La domanda attuale: vantaggi e svantaggi
- Quali sono i pro e i contro di ciascuno di questi approcci?
- Sarebbe tecnicamente irrealizzabile o poco pratico?
- Sarebbe impossibile per C # interagire con un assembly che "sta abusando" del CLR o qualcosa del genere? (nota, la domanda non è specifica per .NET, e potresti anche basare la tua risposta su linguaggi JVM come Scala, o qualsiasi altra cosa tu conosca meglio)
- Ci sono delle lingue in cui è stato utilizzato l'approccio inferuto? (su un livello superiore come .NET a .NET, e non solo lingue con un FFI a codice di basso livello o simili)