Il modo migliore per gestire l'interoperabilità linguistica

5

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)
posta nilu 10.10.2014 - 18:25
fonte

1 risposta

1

Uno dei problemi è la programmazione di un modello. L'altro problema è la programmazione su una macchina. Quindi puoi programmare un modello e creare una compilation intermedia che mantenga qualsiasi tipo di caratteristica speciale. L'intermedio deve quindi essere qualcosa che programma una macchina. Possono esserci codice aggiuntivo fornito con le librerie di supporto che forniscono compatibilità per espandere la comprensione della macchina o per eseguire il downgrade di ciò che viene eseguito dal codice.

Ignorare il codice funzionale da C # non migliora F #. F # sta attualmente modellando in uno stile simile a Ocaml (ma per un ecosistema .Net) con miglioramenti ed è più una situazione di F # che funziona con il runtime e il sistema di tipi. Se espandi ciò che può essere espresso da quel runtime, ogni lingua può trarne vantaggio.

Poiché i delegati sono progettati come un metodo, classi che sono usate per incorporare unità di esecuzione, cose come le funzioni lambda in C # sono già avvolte sottilmente. F # fa una cosa simile con i moduli come classi con metodi statici. Questo è tutto gratis.

Non è impossibile separare una lingua da un'altra. Non è pratico rendere le lingue più difficili da interoperare. I motivi sono molti obiettivi sono estendere e migliorare il runtime per consentire più lingue e incoraggiare l'utilizzo di librerie incrociate. In particolare con C #, non è limitato in quale libreria può chiamare se può consumare valori esposti e sensibili al suo sistema di tipi. Il codice può essere pericoloso e può essere contrassegnato come tale. Potrebbe (eventualmente con alcune funzionalità future) il codice di mark come avanzato per consentirgli di fare di più che può essere fatto in IL.

Il problema di gestire il codebase per i controlli che supportano le funzionalità extra nel compilatore e nei generatori è di arricchire alcuni utili modelli di codice trovati. Quindi, se si è di tipo generico, il compilatore genererebbe versioni per ogni tipo di ogni tipo che è una possibilità risolvibile o una base generatore generatore pigro in uso. Allora penserai a che cosa viene considerato un tipo? È solo una ricerca di tabelle per usi o ambiti inclusi?

La semplice risposta è tempo e desiderio. Poiché l'influenza esterna esprime le sue varie opinioni su questioni e il tempo si assegna a tali questioni, giunge l'attenzione degli autori primari a considerare le opzioni. Il sito usersvoice aiuta. Io stesso ho interesse nei macro igienici per espandere al di là di cosa e come scrivo codice. Grazie. Buona giornata.

    
risposta data 01.10.2016 - 05:35
fonte