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.
- 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.