The Bel language is written in the Bel language.
In 1960, John McCarthy described Lisp, a new type of programming language. I say "new type" because Lisp was not just a new language, but a new way of describing languages.
To define Lisp, he started with a small set of operators, a kind of axioms, which he then used to write an interpreter for the language itself.
He did not intend to describe a programming language in the usual sense, a language used to tell a computer what to do. In his 1960 paper, Lisp was understood as a formal model of computation akin to a Turing Machine. McCarthy didn't think about using it on computers until it was suggested by Steve Russell, his graduate student.
Lisp in 1960 didn't have features common in programming languages. For example, there were no numbers, errors, or I/O. So the people who used Lisp as the basis for the languages ββused to program computers had to add those features themselves. And they did this by abandoning the axiomatic approach.
The development of Lisp thus proceeded in twoβand apparently quite independentβstages: the formal stage, introduced in the 1960 paper, and the implementation stage, in which the language was adapted and extended to run on computers. The main work, if measured by the number of implemented opportunities, was at the implementation stage. A 1960 Lisp translated into Common Lisp is only 53 lines long. It only does what is necessary to interpret expressions. Everything else was added at the implementation stage.
My hypothesis is that, despite its difficult history, Lisp benefited from the fact that its development took place in two phases; that the original exercise of defining a language by writing its interpreter in itself gave Lisp its best qualities. And if so, why not go further?
Call us is an attempt to answer the question: what if, instead of moving from the formal stage to the execution stage at an early stage, to make this transition as late as possible? If you keep using the axiomatic approach until you have something close to a complete programming language, what axioms will you need, and what will the resulting language look like?
I want to be clear about what Bel is and what it is not. Although it has many more features than McCarthy's 1960 Lisp, Bel is still a product in a formal phase. Like Lisp, described in the 1960 paper, it is not a language you can use to program. Mainly because, like McCarthy's Lisp, it doesn't care about efficiency. When I add something to Bel, I describe the meaning of this addition without trying to provide an efficient implementation.
For what? Why extend the formal stage? One answer is to see where the axiomatic approach can take us, which in itself is an interesting exercise. If computers were as powerful as we would like, what would languages ββlook like then?
But I also believe that it is possible to write an efficient implementation based on Bel, adding restrictions. If you want a language that has expressive power, clarity, and efficiency, it might be worth starting with expressive power and clarity, and then adding restrictions rather than going in the opposite direction.
So if you want to try writing an implementation based on Bel, you are welcome. I will be one of the first users.
Ultimately, I reproduced some things from previous dialects. Either their designers did everything right, or, being influenced by previously used dialects, I do not see the right answer - time will tell. I also tried not to stray too far from Lisp's conventions. Which means that if you see a departure from the Lisp conventions, there may have been reasons for that.
.
Thanks for the translation: Denis Mitropolsky
PS
Source: habr.com