Evlan is a purely functional language. This means that Evlan code is composed of expressions, and executing that code means evaluating the expressions. Other examples of functional languages include ML, Haskell, Scheme, and LISP. In contrast, languages like C, C++, C#, Java, BASIC, PASCAL, Perl, Python, and almost every other widely-used language are imperative. Imperative code consists of a list of operations which are to be performed in sequence.
If one wanted to state the advantage of functional languages as briefly as possible, one might say this: In a functional language, you are defining a problem to be solved. In an imperative language, you are telling the computer exactly what steps to take to solve it. Thus, in a functional language you are telling the compiler what to do, but not how to do it. This means less work for you, fewer opportunities to screw up (fewer bugs), and that the compiler will probably be able to produce a more efficient list of steps than you could.
Many papers, books, and web sites have been written which explain functional programming in more detail, so I will not attempt to do so here. Instead, you might try reading the Wikipedia article on functional programming. I do wish to cover a few specific points, however.
Imperative Tasks in Evlan
Because Evlan is purely functional, no function call is allowed to have "side effects". You might wonder, then, how Evlan programs manage to do things like access the hard drive or communicate over the network. The answer is actually pretty simple.
Evlan defines a type of value called a "task". A task describes some imperative (side-effecting) operation which you want the system to perform. To start an Evlan program, you must provide the system with an initial task to execute. Usually, once a task has been completed, the system calls an Evlan function. That function takes, as its parameter, the results of the task. The function then returns a new task to perform next. Thus, the loop continues, with the system repeatedly performing tasks then calling Evlan functions to produce new tasks.
In order to make it easier to write programs that perform many tasks in sequence, Evlan provides the "do" keyword. "do" is followed by a block listing one task to perform per line. Combined with the standard if-then-else expression and API calls to manage loops, programming with the "do" keyword is fairly similar to programming in any imperative language. This is only syntactic sugar, however, which is compiled down to a group of functions that handle each of the tasks involved. Furthermore, you are generally encouraged to do as much work as possible in purely functional code without using tasks.
This exact method is, as far as I know, unique to Evlan. Haskell, another purely-functional language, solves the same problem using "monads". It is my opinion that monads are somewhat more complex than Evlan's solution while providing no real advantages.
Note that future versions of Evlan may move to a different system for imperative operations. In particular, I am studying ways to integrate the ideas from this study, which suggests that humans like to write rules of the form "When condition X is true, do Y". I am not yet sure to what extent this will change the current system, however.
Functional Bytecode
Bytecode for the Evlan virtual machine uses a functional representation of the code. In contrast, the VMs of Java and .NET use assembly-like imperative instructions. Distributing code in its functional form allows far more machine-dependent optimization to take place. That is, the software can be more easily tailored to the exact abilities and timings of the user's own system, whatever type of system that may be.
Indeed, to fully optimize bytecode like Java's or .NET's, the JIT compiler essentially has to reverse-compile the assembly instructions in that bytecode in order to re-compile it for the host system. This is a waste of effort and gives poor results.
Does this mean that the Evlan virtual machine can only support purely functional languages? Not at all. Interestingly, recent versions of GCC (the GNU C Compiler) convert code into a form using "Static Single Assignment" while compiling. This form is actually very close to being equivalent to a purely functional language. If GCC does this internally just to make optimization easier, then it doesn't take a huge stretch to imagine a system which compiles imperative code to functional bytecode for distribution.
Learning Functional Languages
One reason why functional languages have had trouble finding wide use in the software industry is that many programmers, upon first trying to use functional programming, simply do not understand it. The problem is, when imperative programmers decide to learn a new imperative language, they usually find it quite easy. Imperative languages are all pretty similar and require the same basic techniques. On the other hand, functional languages actually force you to approach problems from a completely different perspective. To someone who is only experienced in imperative languages, this new perspective will be confusing and difficult at first. It may even feel as if you are learning to program all over again. Because of this, many programmers dismiss functional programming too quickly.
Consider this: It is rare to find a programmer who has extensive experience in both functional and imperative programming who does not insist that functional programming is, in general, better. Sure, there are specific situations where an imperative language may be more effective, but in general you will get more done in less time using a functional language, if you know how to use them.
Implementation Status: All versions of Evlan are functional languages. The version 0.3 prototype does not export bytecode, but builds a "functional bytecode" representation internally.
References: See the Wikipedia article on functional programming, which contains many links to related information.