La lingua Bel è scritta nella lingua Bel.
Nel 1960, John McCarthy descrisse il Lisp, un nuovo tipo di linguaggio di programmazione. Dico "nuovo tipo" perché Lisp non era solo un nuovo linguaggio, ma un nuovo modo di descrivere i linguaggi.
Per definire il Lisp, ha iniziato con un piccolo insieme di affermazioni, una sorta di assiomi, che ha poi utilizzato per scrivere un interprete per il linguaggio stesso.
Non si proponeva di descrivere un linguaggio di programmazione nel senso comune del termine, un linguaggio utilizzato per dire a un computer cosa fare. Nel suo lavoro del 1960, il Lisp era inteso come un modello formale di calcolo simile alla Macchina di Turing. McCarthy non pensò di usarlo sui computer finché Steve Russell, il suo studente laureato, non lo suggerì.
Il Lisp nel 1960 non aveva le caratteristiche comuni ai linguaggi di programmazione. Ad esempio, non c'erano numeri, errori o I/O. Quindi le persone che utilizzavano il Lisp come base per i linguaggi utilizzati per programmare i computer dovevano aggiungere queste funzionalità da sole. E lo hanno fatto abbandonando l’approccio assiomatico.
Pertanto, lo sviluppo del Lisp procedette in due fasi, apparentemente del tutto indipendenti: una fase formale, introdotta in un articolo del 1960, e una fase di implementazione, in cui il linguaggio fu adattato ed esteso per funzionare sui computer. Il lavoro principale, se misurato in base al numero di opportunità implementate, è avvenuto nella fase di implementazione. Il Lisp del 1960, tradotto in Common Lisp, contiene solo 53 righe. Fa solo ciò che è necessario per interpretare le espressioni. Tutto il resto è stato aggiunto in fase di implementazione.
La mia ipotesi è che, nonostante la sua storia difficile, il Lisp abbia tratto vantaggio dal fatto che il suo sviluppo è avvenuto in due fasi; che l'esercizio originale di definire una lingua scrivendovi il suo interprete ha dato a Lisp le sue migliori qualità. E se sì, perché non andare oltre?
Bel è un tentativo di rispondere alla domanda: e se, invece di passare tempestivamente dalla fase formale a quella esecutiva, questo passaggio avvenisse il più tardi possibile? Se continui a utilizzare l'approccio assiomatico finché non avrai qualcosa di simile a un linguaggio di programmazione completo, di quali assiomi avrai bisogno e come sarà il linguaggio risultante?
Voglio che sia chiaro cosa è Bel e cosa non è. Sebbene abbia molte più caratteristiche del Lisp di McCarthy del 1960, Bel è ancora un prodotto nella sua fase formale. Come il Lisp, descritto in un articolo del 1960, non è un linguaggio utilizzabile per programmare. Principalmente perché, come il Lisp di McCarthy, non si preoccupa dell'efficienza. Quando aggiungo qualcosa a Bel, descrivo il significato dell'aggiunta senza tentare di fornire un'implementazione efficiente.
Per quello? Perché estendere la fase formale? Una risposta è vedere dove può portarci l’approccio assiomatico, il che è di per sé un esercizio interessante. Se i computer fossero potenti come vorremmo, come sarebbero le lingue?
Ma credo anche che sia possibile scrivere un'implementazione efficiente basata su Bel aggiungendo restrizioni. Se desideri un linguaggio dotato di potenza espressiva, chiarezza ed efficienza, potrebbe valere la pena iniziare con potenza espressiva e chiarezza, quindi aggiungere restrizioni, piuttosto che andare nella direzione opposta.
Quindi, se vuoi provare a scrivere un'implementazione basata su Bel, vai avanti. Sarò uno dei primi utenti.
Alla fine ho riprodotto alcune cose dei dialetti precedenti. O i loro progettisti hanno capito bene, oppure essendo influenzato dai dialetti usati in precedenza, non vedo la risposta giusta: il tempo lo dirà. Ho anche cercato di non allontanarmi troppo dalle convenzioni Lisp. Ciò significa che se vedi un allontanamento dalle convenzioni Lisp, potrebbe esserci una ragione per questo.
.
Grazie per la traduzione: Denis Mitropolsky
PS
Fonte: habr.com