 My name is Sean Young, and I'm going to present the Solang Clwydde Compiler, so I have about 20 slides to go through, so I'll go through these fairly quickly. So what is Solang? It's a Solang Clwydde Compiler with compulsority into WebAssembly. It targets different blockchains, so currently targets substrate, e-wasm and sawtooth, and other ledgers, if they're interested, could add themselves. Now that the LLVM back-end is stabilising, that would be a very interesting target to add. So Solang is written with different tooling than SolC, so it's written in Rust. When you write in a compiler yesterday with ASTs and control flow graphs, and these are represented actually quite well in Rust enums, so I think Rust is a quite suitable language. It uses LLVM as a library, so it uses LLVM for its optimisation parses and to write out the wasm file itself. There are also some other advantages to using LLVM, which I'll talk about later. It has a Solidity grammar, and from that, the parser is generated. So recently I've been adding tri-catch and adding this to the parser, which is about 10 lines of code, so it's fairly straightforward with a generated grammar. So on different blockchains, there are some underlying differences, which might be visible in the language. So in substrate, the address type is 256 bits by default. It can actually be different from that depending on how substrate is compiled. So the address type in Solidity is different. Also, constructors can be overloaded in substrate, and substrate uses different ABI encoding than Ethereum. Lastly, there's a print function, which is just useful for debugging. This is only available in development chains, but it does really help. So here's a funny little example of a Solidity contract on substrate. So we have an overloaded constructor. The ABI encodes a function selector for the constructor. The ABI encoding for N64 is simply 8 bytes little endian. So all the types are fairly simply encoded. So we have a function hello, which takes a string. A string simply has a single field with length followed by the bytes of the string in the ABI encoding. And then we have a print function call, which is a built-in which calls the substrate print. And maybe we also can do string concatenation. I'll talk a little bit more about that later. So a brief history of Solang. Is my screen very blurry? No, just crystal clear for me. Okay, okay, it's really for me. Okay, so in March I wrote a prototype. So this was a simple grammar for a very limited set of Solidity, some LLVM. And within a weekend of hacking I could get a very primitive contract to run. So late in December I was awarded a grant from the Web Pre-Foundation. And this was specifically to complete Solidity language support for substrate. This was divided into 10 milestones. Five of those have already completed. So these are the remaining milestones for the Web Free grant. And this, in September, this will end. This should mean that Solang has feature language support complete. It doesn't mean that the output is optimal. The first aim is to get language correct. Also, there will be differences between Solci and Solang language. For example, on Wazm it would be quite difficult with the current scheme to support assembly statements. Also, there are some additions, like the print thing I just talked about, and the different ABI encoding on different chains. So a little bit about how Solang has been. When I set out to write Solang, I wanted to build a traditional compiler. I didn't want to do anything revolutionary. I also wanted to be simple. So there are some fairly simple stages to the compiler. So the first thing a compiler always does is passing. So we have an LLR grammar. And we have a custom nexa. And the lexa is really needed because of the pragma statements. So if a lexa tokenizes pragma utility with the Simva, then it will produce a lot of tokens when it shouldn't. It should just take the value as everything up to the first semi colon. So the next stage in the compiler is the resolver. So the parser outputs the abstract syntax tree. And the resolver resolves all the symbols in that, generates all the warnings and errors, et cetera. And in Solang, in order to make it simple, it goes straight from AST to a control flow graph. This is actually where the bulk of the code is in the project. This is where all the language support really is. And this is also a front-end compiler because it uses LLVM. So the next part is there's also a standard library. So this is some C code which gets compiled into LLVM IR by Clang. And this gives us a heap. So we have malloc and realloc, et cetera. We can implement things like string compare and string concatenate. We have a catalogue hash for changes that are provided. That's what we have at the moment, but this can be expanded to have much more things you might want in a language. So in the print statement earlier, it would be useful to be able to print ints or address this or so. So string formatting would be a very useful thing. And that would be implemented in C added to the standard library. And then compiled into LLVM IR. And then this will be linked into one big LLVM code. And then using global dead code elimination, any unused functionality will be removed. So having a large standard library doesn't mean that the resulting wasm file would be any bigger. So the last stage of the compilation is the emitter. The control flow graph generated by the resolver is specifically geared towards LLVM. So there's mostly one-to-one mapping. We have to do some tricks for firing nodes. We also have to generate some specific things for wasm. So because wasm doesn't support 256-bit arithmetic, we have to have some arithmetic functions. We have to have an ABI encoder decoder. So we have an ABI encoder decoder for Ethereum ABIs, and we have one for parity scale ABIs. It also does the linking, mid-solid library, and it does add some touch-ups to the final wasm in order to make it correct. And there's this custom code for each particular target to generate target-specific calls to the externals, for example. Lastly, we also need ABIs. So in this directory, in source ABI, we have some codes to generate ABIs. In substrate, these are called metadata files. This is because in substrate, the file contains more than just the functions from structures and events. It contains names, comments, what compiler version generated the file. In future, it may contain the hash of the wasm, so you can check the ABI against the wasm to make sure it's the correct one. So Langis, a Hyperledger project and Hyperledger have a dementia programme, which is a bit like Google Summer of Code. Through this, this year, there's a dementia programme for a Solang language server. So this is for IDs. So in an ID, when you write a facility, it can tell you where errors and warnings are. It can do syntax highlighting, give you information about identifiers, et cetera. Things that make life easier when you're writing code. So that's a mentorship having this year. Hopefully be more next spring. I have to wait and see, of course. So here's some future ideas of things I would like to work on, but nothing has been done so far. So one of the advantages of using LLVM is that we can use the LLVM linker. So anything that can compile to LLVM IR can be linked. So if a facility had a foreign function interface, then any C code or Rust or whatever could be called from facility and then linked into the Wasm. People want to run all sorts of crazy stuff on chain, so this would help them do that. Also this could be helpful to add crypto, because it's written in C to smart contracts. Another thing is we would like to push and pop on memory arrays, because we have a heap in the library and a realloc. This actually isn't that hard to implement. This is just a question of wiring things up. The other thing I've had many people ask about is improved data structures and stability. So we want hash maps, linked lists, sets, trees, all sorts of things, either in memory or in contract storage. It would be great to have those available. If you have hash maps, et cetera, you might want generic types to use those. So something like coming in TypeScript would be great. This is all hypothetical, really. I really would like to collaborate with a source C team and see what they think. I do not necessarily want to take Solidity in its own direction and away from the official Solidity. It's just ideas of what would be good. The other thing with Sun of the Library could have much better string processing. Let's just make life easier for when you're debugging code. As Lionel Storval said, all you need is printf in order to debug any problem. Let's just make life so much easier. That's it, actually. It's just me working on a project now. There are people interested. If you want to get in touch or ask any questions, please do. Thank you very much for your time. Great. Awesome. Thank you, Sean. All right. Same procedure as every talk. If you have a question in the room, please do raise your hand or shout so that I know that you would like to speak. For the people on the live stream, we will give you a minute now to think about if you have questions, then please put them in the guitar chat. You know you have it today, so we are waiting for you. Anybody here in the room has any questions with regards to the Solang Solidity Compiler? Yes, Chris. Thanks for your talk. I agree that we should come together more and talk about potential features. The main problem I see is that the language you're working on has a substrate as the main and maybe only target. This is why your language and Solidity sometimes have to make different trade-offs. I don't know. I just wanted to say that. For example, memory push and pop. If you have a heap and memory is cheap, then this is certainly a good idea, as a feature facility. We try to not add features that lure people into thinking that the operation might be cheap, but it is not in the end. There is a certain trade-off we have to make here. I think you are muted. Thank you. I totally agree. When e-wasm happens, then some of these concerns might go away around memory usage, et cetera. Also, now that the LLVM EVM backend is becoming quite stable, I think it would be quite interesting to add that as a target to Solang as well. I would be very much interested in some benchmarks there for the LLVM EVM backend. Yes.