La lingua funzionale senza runtime scritto in C è possibile? [chiuso]

Is there still any functional programming language that doesn't rely on C runtime?

Sì, almeno se consideri (come faccio io) che le varianti Lisp sono linguaggi funzionali (perché hanno gli operatori di applicazione e astrazione di lambda-calculus ), e che qualsiasi lingua con chiusure e astrazione è funzionale:

• Bones è un'implementazione di Scheme , compilato per codice assembly x86-64 nella sintassi nasm , che può essere compilato senza utilizzare alcun compilatore C (ma usa gcc come linker solo; con una conoscenza sufficiente, puoi sostituirlo con ld ).

• Scheme48 è un'altra implementazione di Scheme che è interamente compilata in C; AFAIK il suo sistema di runtime (incluso il suo GC) è codificato in un sottoinsieme di Scheme chiamato PreScheme, ed è tradotto in C (quindi l'IUC non contiene alcun codice C scritto in italiano)

• Il CAIA di Jacques Pitrat è un sistema di intelligenza artificiale bootstrap con linguaggio dichiarativo ( e tutto del suo codice C viene generato da solo), quindi non contiene alcun codice C scritto da umani (ma usa C come linguaggio oggetto di destinazione, come molte altre implementazioni)

• Lissac è un linguaggio orientato agli oggetti con alcune abilità funzionali (AFAIK ha chiusure quindi può contare come funzionali linguaggio di programmazione) interamente compilato nel codice x86-64.

• le vecchie macchine LISP degli anni '80 non si basavano affatto su C.

Probabilmente stai chiedendo: come può essere un sistema runtime scritto in un linguaggio funzionale di alto livello (una specie di problema di gallina e uova, chiamato compilatori bootstrap ). La risposta è "semplice" in linea di principio; è necessario assicurarsi che la parte inferiore del runtime non abbia bisogno di alcun runtime (ad esempio qualsiasi garbage collection) quando viene eseguito. Questo può essere complicato da codificare (se non si dispone di strumenti che assicurano tale proprietà) e in genere è necessario conoscere alcuni dettagli di implementazione del compilatore e utilizza un costrutto di base non sicuro (ad esempio quello che richiede memoria da il sistema operativo, ad esempio attraverso la funzione POSIX mmap o il sottostante mmap(2) sistema chiamare )

I know that there are some projects that somehow compile OCaml (...) to run on bare bones Xen hypervisor

Probabilmente stai pensando a MirageOS , un unikernel codificato principalmente in Ocaml. Ma utilizza un adattamento del runtime di Ocaml (in particolare il GC) portato su Xen e codificato a mano in C. Xen è un hypervisor emulando (in una VM) una sorta di sistema hardware x86-64, quindi non fornire alcun garbage collector (ma astrae alcuni dispositivi hardware comuni e forse driver di livello molto basso).

Si noti che C è ampiamente usato come "assemblatore portatile". Puoi utilizzare LLVM (o C-- di S.Peyton Jones e Norman Ramsey, che purtroppo è in fase di stallo) per quel ruolo (ma LLVM è scritto in C ++).

Is there still any functional programming language that doesn't rely on C runtime?

La risposta a questa domanda esatta è sì: C non è l'unico linguaggio di basso livello adatto come target di compilazione (anche se sicuramente il più popolare). Ad esempio, l'Embedded ML descritto in Programmazione funzionale per lo sviluppo di software di volo embedded di A. J. Harris ha un runtime Forth (oltre a uno C).

La risposta alla tua altra domanda, vale a dire "è possibile implementare un linguaggio funzionale tutto in sé", cioè senza un enorme runtime scritto in una lingua esterna, è anche sì per quanto mi riguarda. Tipi di unicità , come presentato ad es. il linguaggio Clean, abilita la possibilità di modellare aggiornamenti distruttivi mantenendo una trasparenza referenziale. Il linguaggio Mercury, che è menzionato nella tua domanda, ha una funzione Garbage Collection Compile Time, che elimina la necessità di un GC convenzionale. La pigrizia, credo, deve essere gestita in modo esplicito, vale a dire che non si può avere una semantica vera chiamata senza necessità del supporto di runtime, ma si possono ancora implementare strutture dati pigre che coprirebbero la maggior parte del bisogno di pigrizia.

Credo che la ragione per cui non vediamo nessun linguaggio funzionale tradizionale implementato in questo modo è che, sebbene sia possibile, è piuttosto poco pratico farlo, a causa dell'efficienza e dei motivi di complessità del linguaggio.

In linea di principio? Sì. C è un linguaggio di programmazione come tutti gli altri. Cosa C può fare, altre lingue possono essere fatte per fare.

In pratica? Raramente. C è quasi ubiquitario come linguaggio di programmazione dei sistemi (ci sono delle eccezioni, ma saranno forniti nei commenti oltraggiati, quindi non mi preoccupo di elencarli), ed è quasi sempre un'idea migliore usare ciò che è già disponibile di scrivere il proprio involucro del SO di basso livello. (C'è anche un po 'di sinergia nel fatto che molti kernel del sistema operativo sono essi stessi scritti in C, quindi chiamare le convenzioni ecc. È un po' più facile da gestire quando si usa C). C'è valore nell'avere uno standard universale, anche se è un vecchio standard verrucoso come C, quindi le persone raramente si preoccupano di evitarlo apposta.