Bel-sproget er skrevet på bel-sproget.
I 1960 beskrev John McCarthy Lisp, en ny type programmeringssprog. Jeg siger "ny type", fordi Lisp ikke bare var et nyt sprog, men en ny måde at beskrive sprog på.
For at definere Lisp startede han med et lille sæt udsagn, en slags aksiomer, som han så brugte til at skrive en tolk til selve sproget.
Den havde ikke til formål at beskrive et programmeringssprog i sædvanlig forstand – et sprog, der bruges til at fortælle en computer, hvad den skal gøre. I sit værk fra 1960 blev Lisp forstået som en formel beregningsmodel, der ligner Turing-maskinen. McCarthy tænkte ikke på at bruge det på computere, før Steve Russell, hans kandidatstuderende, foreslog det.
Lisp i 1960 havde ikke de funktioner, der var fælles for programmeringssprog. For eksempel var der ingen tal, fejl eller I/O. Så folk, der brugte Lisp som grundlag for de sprog, der blev brugt til at programmere computere, skulle selv tilføje disse funktioner. Og det gjorde de ved at opgive den aksiomatiske tilgang.
Udviklingen af Lisp forløb således i to - og tilsyneladende ret uafhængige - stadier: en formel fase, introduceret i et papir fra 1960, og en implementeringsfase, hvor sproget blev tilpasset og udvidet til at køre på computere. Hovedarbejdet, hvis målt ved antallet af implementerede muligheder, fandt sted på implementeringsstadiet. Lisp fra 1960, oversat til Common Lisp, indeholder kun 53 linjer. Den gør kun, hvad der er nødvendigt for at fortolke udtrykkene. Alt andet blev tilføjet på implementeringsstadiet.
Min hypotese er, at Lisp på trods af sin vanskelige historie nydt godt af, at dens udvikling skete i to faser; at den oprindelige øvelse med at definere et sprog ved at skrive dets tolk i det gav Lisp dets bedste egenskaber. Og hvis ja, hvorfor så ikke gå videre?
Smukke er et forsøg på at besvare spørgsmålet: hvad nu hvis denne overgang i stedet for at gå fra den formelle fase til udførelsesfasen på et tidligt tidspunkt blev foretaget så sent som muligt? Hvis du fortsætter med at bruge den aksiomatiske tilgang, indtil du har noget tæt på et komplet programmeringssprog, hvilke aksiomer har du brug for, og hvordan vil det resulterende sprog se ud?
Jeg vil gerne være klar over, hvad Bel er, og hvad det ikke er. Selvom det har mange flere funktioner end McCarthys Lisp fra 1960, er Bel stadig et produkt i sin formelle fase. Ligesom Lisp, beskrevet i et papir fra 1960, er det ikke et sprog, du kan bruge til at programmere. Hovedsageligt fordi den ligesom McCarthys Lisp er ligeglad med effektivitet. Når jeg tilføjer noget til Bel, beskriver jeg betydningen af tilføjelsen uden at forsøge at give en effektiv implementering.
For hvad? Hvorfor forlænge den formelle fase? Et svar er at se, hvor den aksiomatiske tilgang kan føre os hen, hvilket er en interessant øvelse i sig selv. Hvis computere var så kraftfulde, som vi gerne vil have dem til at være, hvordan ville sprog så se ud?
Men jeg tror også på, at det er muligt at skrive en effektiv Bel-baseret implementering ved at tilføje restriktioner. Hvis du vil have et sprog, der har udtrykskraft, klarhed og effektivitet, kan det være værd at starte med udtrykskraft og klarhed og derefter tilføje begrænsninger frem for at gå i den modsatte retning.
Så hvis du vil prøve at skrive en implementering baseret på Bel, så fortsæt. Jeg vil være en af de første brugere.
I sidste ende gengav jeg nogle ting fra tidligere dialekter. Enten fik deres designere ret, eller også er de blevet påvirket af tidligere brugte dialekter, jeg kan ikke se det rigtige svar – det må tiden vise. Jeg prøvede også ikke at gå for langt fra Lisp-konventionerne. Hvilket betyder, at hvis du ser en bevægelse væk fra Lisp-konventionerne, kan der være en grund til det.
.
Tak for oversættelsen: Denis Mitropolsky
PS
Kilde: www.habr.com