Bel-språket är skrivet på bel-språket.
1960 beskrev John McCarthy Lisp, en ny typ av programmeringsspråk. Jag säger "ny typ" eftersom Lisp inte bara var ett nytt språk, utan ett nytt sätt att beskriva språk.
För att definiera Lisp började han med en liten uppsättning påståenden, ett slags axiom, som han sedan använde för att skriva en tolk för själva språket.
Den syftade inte till att beskriva ett programmeringsspråk i vanlig mening - ett språk som används för att tala om för en dator vad den ska göra. I sitt arbete från 1960 uppfattades Lisp som en formell beräkningsmodell som liknar Turing-maskinen. McCarthy tänkte inte på att använda det på datorer förrän Steve Russell, hans doktorand, föreslog det.
Lisp 1960 hade inte de funktioner som var gemensamma för programmeringsspråk. Det fanns till exempel inga siffror, fel eller I/O. Så människor som använde Lisp som grund för språken som användes för att programmera datorer var tvungna att lägga till dessa funktioner själva. Och de gjorde detta genom att överge det axiomatiska tillvägagångssättet.
Sålunda fortskred utvecklingen av Lisp i två - och till synes ganska oberoende - steg: ett formellt skede, introducerat i en tidning från 1960, och ett implementeringsskede, där språket anpassades och utökades till att köras på datorer. Huvudarbetet, om det mäts i antalet genomförda tillfällen, ägde rum på implementeringsstadiet. Lisp från 1960, översatt till Common Lisp, innehåller endast 53 rader. Den gör bara det som är nödvändigt för att tolka uttrycken. Allt annat lades till vid implementeringsstadiet.
Min hypotes är att Lisp trots sin svåra historia gynnades av att dess utveckling skedde i två faser; att den ursprungliga övningen att definiera ett språk genom att skriva dess tolk i det gav Lisp dess bästa egenskaper. Och i så fall, varför inte gå längre?
Bel är ett försök att besvara frågan: tänk om denna övergång gjordes så sent som möjligt istället för att gå från det formella stadiet till utförandestadiet på ett tidigt stadium? Om du fortsätter att använda den axiomatiska metoden tills du har något i närheten av ett komplett programmeringsspråk, vilka axiom kommer du att behöva och hur kommer det resulterande språket att se ut?
Jag vill vara tydlig med vad Bel är och vad det inte är. Även om den har många fler funktioner än McCarthys Lisp från 1960, är Bel fortfarande en produkt i sin formella fas. Liksom Lisp, som beskrivs i en tidning från 1960, är det inte ett språk du kan använda för att programmera. Främst för att den, precis som McCarthys Lisp, inte bryr sig om effektivitet. När jag lägger till något till Bel, beskriver jag innebörden av tillägget utan att försöka tillhandahålla en effektiv implementering.
För vad? Varför förlänga det formella skedet? Ett svar är att se vart det axiomatiska synsättet kan ta oss, vilket är en intressant övning i sig. Om datorer var så kraftfulla som vi vill att de ska vara, hur skulle språken se ut?
Men jag tror också att det är möjligt att skriva en effektiv Bel-baserad implementering genom att lägga till restriktioner. Om du vill ha ett språk som har uttryckskraft, klarhet och effektivitet, kan det vara värt att börja med uttryckskraft och klarhet, och sedan lägga till begränsningar, snarare än att gå i motsatt riktning.
Så om du vill testa att skriva en implementering baserad på Bel, fortsätt. Jag kommer att vara en av de första användarna.
Till sist återskapade jag en del saker från tidigare dialekter. Antingen har deras designers fattat rätt, eller så är de influerade av tidigare använda dialekter, jag ser inte det rätta svaret – det får tiden utvisa. Jag försökte också att inte avvika för långt från Lisp-konventionerna. Vilket betyder att om man ser en avvikelse från Lisp-konventionerna kan det finnas en anledning till det.
.
Tack för översättningen: Denis Mitropolsky
PS
Källa: will.com