Solidity is a complex moving target with limitations such as max 16 local variables, missing optimizations and only partial support for dynamic allocation.
You might want to compile directly to EVM instead of through Solidity. The EVM is very simple, as far as virtual machines go. It's fully documented in [the yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf) and only changes with hardforks (and then only incrementally in a backwards compatible way).
Smart contract development feels like embedded systems development. Every instruction has a significant cost associated to it. There are different memory spaces like a Harvard architecture (code, memory, storage, input, output, other peoples code). Like embedded systems, you need to be absolutely sure your code is correct before you deploy, as updates are impossible and a lot of economic value depends on correctness.
But contrary to embedded systems it has 256 bit registers, 256 bit address space and SHA3 as a cheap instruction. This means that if you pick a 'random' hash, you can safely assume it's free! Hashtables in Solidity are implemented like this.
Suboptimal smart contracts directly incur unnecessary transaction costs for users, and it's hard to imagine that Haskell as a source language would translate to efficient EVM bytecode.
For one, do you really want to have a lazy evaluation runtime compiled into your multisig? Now do you want to prove the correctness of that runtime? ...
I don't think Haskell is anywhere near a good source language for Ethereum smart contracts, if you think of it as "compiling Haskell".
There was a master's thesis about compiling Idris to EVM, and it also shows that the performance problems are difficult indeed even without laziness.
Kansas Lava is a Domain Specific Language (DSL) for expressing hardware-oriented descriptions of computations, and is hosted inside the language Haskell. Kansas Lava programs are descriptions of specific hardware entities, the connections between them, and other computational abstractions that can compile down to these entities. Large circuits have be successfully expressed using Kansas Lava, and Haskell’s powerful abstraction mechanisms, as well as generic generative techniques, can be applied to good effect to provide descriptions of highly efficient circuits.
That's an approach I think is much more appropriate for the strengths and weaknesses of Haskell!
As it happens, we've started very modestly at using Haskell like this. At the moment we only have a simple monadic assembler that lets you write EVM code. See this example:
You might want to compile directly to EVM instead of through Solidity. The EVM is very simple, as far as virtual machines go. It's fully documented in [the yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf) and only changes with hardforks (and then only incrementally in a backwards compatible way).
Smart contract development feels like embedded systems development. Every instruction has a significant cost associated to it. There are different memory spaces like a Harvard architecture (code, memory, storage, input, output, other peoples code). Like embedded systems, you need to be absolutely sure your code is correct before you deploy, as updates are impossible and a lot of economic value depends on correctness.
But contrary to embedded systems it has 256 bit registers, 256 bit address space and SHA3 as a cheap instruction. This means that if you pick a 'random' hash, you can safely assume it's free! Hashtables in Solidity are implemented like this.
Recently I've been doing some combined Solidity/EVM-assembly that I wrote about [here](https://medium.com/wicketh/mathemagic-chinese-remainder-theo...). I'll post more this month doing some advanced tricks in Solidity/EVM.