Better Scheme has, since its beginning as a Winter Term project (read the original project proposal) at Oberlin College, been about understanding what the fundamental concepts of programming languages are and how they fit together to form a whole language. That has been my personal goal, however Better Scheme itself is also a tool for others to learn from and use. To that end I have worked and am still working to make the Better Scheme system as complete and clearly explained as possible, explaining the rational behind why I made the decisions I did about its design and implementation.
I hope that others will use Better Scheme as a model through which to learn how to make and use the next great programming languages. If this is the case then its purpose will have been fulfilled. More specific than this are the goals which I sought in the actual design of Better Scheme, those are:
It is my belief that a language that is self consistent will be more powerful and flexible. If a feature can be used in one place then why not elsewhere. If that introduces problems then reconsider your features. Separate parts of a language should be orthogonal, that is they should not serve the same purpose or said another way they should be independent of each other. The most power will derive from allowing features to be used completely in all interacting situations.
Scheme to me is first and foremost a functional language. If one wanted the power of procedural or object-oriented mutable structures then one would use a language designed for that. The choice to use Scheme should be a choice to embrace the functional style. Whether this is a wise choice I will not judge. With Better Scheme I have sought to make this even more the case, with mutation functions being more shunned and the addition of currying. This makes it easier and more powerful to work in a functional style. At the same time I have balanced support for other paradigms to fit Better Scheme's role as a programmer's scripting language.
Update 2002-06-08: Better Scheme used to have lazy evaluation as well. It has been removed from the language because of the many problems it caused (see Lazy Evaluation? Call by Need vs. Value). Also, lazy evaluation did not coincide with my New Vision for Better Scheme.
The lambda calculus provides a consistent theory of functional computation. It is true that no one should be tortured by being made to write directly in the lambda calculus but it still has many powerful features. In many places Scheme grasps for an explanation of some entity, the answer can usually be found in the lambda calculus. What are truth values, numbers, lists, and characters? The lambda calculus says they are all functions. In Better Scheme any value can be used anywhere not because of latent typing but because all entities are functions.
Finally a language must run reasonably efficiently or it will not be used and likely have little impact. The design of Better Scheme recognizes this fact (for example it, as does Scheme, requires implementations to be properly tail recursive). At the same time the power of a language should not be traded for a little more speed. A balance is needed.
|
jwalker@cs.oberlin.edu |