ALFE design philosophies

Every computer language has its design philosophies. Here are ALFEs:

  • Imperative rather than purely functional. This, this and this have some good points about why functional programming isn't a panacea. However, I'm hoping to implement some features which help to keep the purely functional parts of a program separate from the parts with side effects - the compiler will be able to keep track of which functions are supposed to be pure and prevent them from calling impure functions (with appropriate escapes for things like debugging and encapsulating high performance libraries behind functional interfaces).
  • Statically typed rather than dynamically typed. A type annotation is like a compiler-enforced comment and a unit test rolled into one, at an almost trivial cost. In fact, being used to static typing I now find that when I'm programming in a dynamic language I spend more time wondering what values a variable is supposed to have and tracking down errors that the type system would have caught than I do typing and modifying type annotations in static languages. Plus they're not even compulsory - I'm planning to give ALFE a Variant type which can hold any value (although most of the standard library functions will probably be statically typed so dynamic typing won't have first-class status). Some form of Hindley-Milner style type inference is also something I'd like to do.
  • Strict rather than lazy evaluation. ALFE is a high performance language and general performance characteristics are considered to be an observable behavior. Of course, lazy evaluation as a strategy for particular pieces of code is still possible - I remember when I first understood lazy evaluation reading about strategies for implementing continued fraction arithmetic in HAKMEM and thought it was tremendously clever, though unfortunately I've never had a good reason for implementing it.
  • No garbage collection. Also, the space of garbage collected languages has also been pretty thoroughly explored.
  • Rich in features at the expense of simplicity and ease of learning. In fact, if this language is so complicated that I'm the only one who can use it, that would not in itself cause it to fail to achieve what I'd like to achieve with it.
  • It's primarily a compiled language for maximum speed. Though I am currently planning on having a built in interpreter for the build system. A REPL might come in handy too.
  • The core language is not minimalist - even if some feature could be added as a library, it may still get language support if that would improve it in some way.
  • Text is for input and output, not processing.

I might come back and add some more things to this list as I think of them.

Leave a Reply