That's not really unlike Haskell: in Haskell, you just have a different set of tools for transforming the language.
I just came off a largish project in Racket, and do appreciate that it's very flexible. However, I've found Haskell to be roughly as flexible in practice. Haskell has surprisingly flexible syntax and semantics, and I've found it very easy to have parts of my program with radically different semantics from normal Haskell.
You can very easily layer on things like non-determinism, logic programming, error-handling, asynchronous programming or even continuations onto Haskell code. And since it's lazy by default, you do not have to do anything special to add new control structures--you don't even need to use the macro system. (Which, of course, Racket does much better--template Haskell works, but it's a bit of a pain.)
I've also spent some time embedding DSLs in both Racket and Haskell, and have found that they are about roughly equally convenient. Racket is more flexible syntactically--it's very easy to do things like inspect variable names and the like. Haskell, on the other hand, has some very lightweight tools (laziness, do notation and a very spartan syntax) that make it very easy to change its semantics. The type system--especially things like GADTs--also makes life much easier for DSLs.
Haskell introduces restrictions with its non-homoiconic syntax, static type system, and pure effects system. I am not yet convinced that these restrictions are necessary.
- I am not convinced that it is worth it to throw out the benefits of homiconicity in order to create a distinction between code and data. I find that Haskell's heteroiconic syntax is actually harder to read and write then S-expressions.
- In mathematics all sets of the same cardinality are isomorphic. In assembly language there isn't really any notion of types besides cardinalities counted in bits. I am not convinced that we need to introduce a system of static typing besides an optional system of cardinalities. I am skeptical of the claims that we need static typing to eliminate errors and bugs.
- I am not convinced that we should have purely functional programming based upon monadic IO rather then other alternatives like uniqueness types. Perhaps a better option is to have a term rewriting and macro expansion phase that is purely functional and to encapsulate all side effects in a seperate evaluation phase.
If you are certain that Haskell's non-homoiconic syntax, static type system, and pure effects system exist in the right form for what you want to do then by all means use them. Otherwise, consider that Lisp doesn't distinguish between code and data so it gives you unprecendented freedom to shape the language into the form that suits you best.
> (laziness, do notation and a very spartan syntax)
I do not know whether spartan is the right adjective. The Haskell syntax is rather bendable, but that's because you can do almost everything with the basic tools of operators and function calls. On the other hand, the Haskell syntax space is rather crowded already, and it's not trivial to add without hitting something that's already there.
I just came off a largish project in Racket, and do appreciate that it's very flexible. However, I've found Haskell to be roughly as flexible in practice. Haskell has surprisingly flexible syntax and semantics, and I've found it very easy to have parts of my program with radically different semantics from normal Haskell.
You can very easily layer on things like non-determinism, logic programming, error-handling, asynchronous programming or even continuations onto Haskell code. And since it's lazy by default, you do not have to do anything special to add new control structures--you don't even need to use the macro system. (Which, of course, Racket does much better--template Haskell works, but it's a bit of a pain.)
I've also spent some time embedding DSLs in both Racket and Haskell, and have found that they are about roughly equally convenient. Racket is more flexible syntactically--it's very easy to do things like inspect variable names and the like. Haskell, on the other hand, has some very lightweight tools (laziness, do notation and a very spartan syntax) that make it very easy to change its semantics. The type system--especially things like GADTs--also makes life much easier for DSLs.