Axel aims to combine the semantics of Haskell, the syntax of Lisp, and the ecosystem of the JVM/Node/etc.
Regarding a combination of Haskell and Lisp, I was inspired by the awesome Hackett project, which implements Haskell on top of Racket, since I'd always wanted to try Lisp but kept running back to Haskell and the experience of programming in its incredible type system. However, since Hackett is inherently tied to the Racket ecosystem, it wasn't quite was I was looking for.
Lisp on the JVM/Node is nicely solved by Clojure(Script), but I'd hate to have to give up Haskell's semantics. Haskell on the JVM/Node, on the other hand, has been conquered by Eta and PureScript (for example), but their non-Lispiness stands.
So, I started by imagining what a Lisp built on top of Haskell would look like. My brief forays into Template Haskell had originally made me hungry for a simpler Haskell macro system (even if that meant trading type safety for ease-of-use), and Lisp's fit the bill. I love the minimalistic elegance of Haskell's syntax, and Lisp's virtual lack of syntax seemed to take that approach to its logical conclusion.
Basically, Axel was born to fill a hole that I kept finding myself wishing for. It stays close to its Haskell roots – most Haskell code can be easily converted into its equivalent Axel representation – but sports a Common Lisp-esque macro system that allows for incredible syntactic flexibility. Many GHC language extensions (such as LambdaCase or ApplicativeDo), which would otherwise be built-in to the compiler, can instead be implemented as macros. Even Axel's do-notation is nothing more than a standard library macro!
Axel is still in its infancy (having just exited the proof-of-concept stage), and a basic roadmap can be found here. The goal I'm most excited about is creating backends other than Haskell, as tapping into larger ecosystems than Haskell's has always been one of Axel's overarching goals. The Haskell backend is the first step on this journey (mainly because I'm less familiar with PureScript or Eta), and as a result, bootstraping the Axel transpiler to use Axel rather than Haskell might happen relatively soon. However, I'm keeping sight of the plan to target PureScript (i.e. Node) and Eta (i.e. the JVM), because I personally believe they their easy access to huge ecosystems, while retaining Haskell's focus on purity, provides them with significant advantages. And in the case of PureScript, for example, Axel will be able to add metaprogramming facilities to a language that does not have such capabilities of its own.