Language like Rust
I am curious! I currently have multiple different projects I am doing(some I still have to continue that I started from a while ago).
But, while I am at it, should I create a language like Rust? Using C, of course. I could use some contributors as well, if anyone would be down?
What do you think?
Yeah, a Rust-like language written in C would be cool. I'm actually learning to write a C-like language in Rust at the moment lol
@MocaCDeveloper Once I get the parser into a useable state, I might want some help writing the compiler. I have no idea whether or not you're experienced with LLVM specifically, but I've looked through your projects before and you seem to know what you're doing when it comes to compilers.
Also very understandable!
I am currently working on a security application in C and it is quite hard. I am creating my own virtual memory to be allocated and assigned throughout the program to reference "chunks" of data to be encrypted.
Then this virtual memory that I created will be "turned" into a stream of chunks of encrypted information, then formatted into the stream of encrypted information to be written into the binary file.
Then, the decoder will be written in rust!
Head up. The parser is where the syntax tree is created. Any and every language has what is called a syntax tree.
A syntax tree is the "outline" of the files code. Look at it like this:
Lets say we have
print('HEY') in a file. The syntax tree will pickup the print method, and store in the value the print method is to print out.
The only step that changes between interpreted and compiled languages is how to syntax tree is put to work.
In interpreted languages, the code is all "compiled" in the interpreter, where the syntax tree is "taken apart" and whatever it has stored is thus compiled.
In compiled languages, the syntax tree is taken in to be converted into assembly. The actual syntax tree itself is never used thus more after the assembly code is generated.
So, primarily, the syntax tree is just something to represent all of the functional code within the file so you can write appropriate assembly code for it.
Meanwhile, in a interpreted language, that syntax tree is put to use from the parser and beyond! Which is why interpreted languages tend to be slower.
I would personally stick with recursive parsing. To me, it’s just going to be way easier than any other type of parsing
I have only experimented with recursive parsing since it’s easier. It’s basically reading the code “step-by-step” or rather, instruction by instruction.
Unlike a compiler like GCC that takes in the whole source code and does nothing with it until compilation.
Interesting. I have never even thought of what it would be like to create a language in Rust.
A few things I want to point out are:
- Lines 17 and 18
- the grammar.pest file
Lines 17 and 18
#[derive(Parser)] #[grammar = "grammar.pest"]
#[derive(Parser)] do? Does it have some type of special affect on the IdentParser struct? And if so, what is it?
As for the grammer.pest file. What is it. Is this some type of file to do with LLVM? Because it's stated in the rust file,
[grammer = "grammar.pest"]. So does this pest file have some type of relations with Rust? Or is it just a easier way to parse a file?
#[derive]is for implementing a trait. I'm not too good with rust, I just know that your parser struct needs to
[derive(parser)]in order to work.
grammar.pestfile is the grammar used by the parser. The kind of parser I'm using is a PEG parser. What makes this kind unique is that rather than relying on a lexer to tokenize the input, it uses a grammar to tokenize as it parses. This has nothing to do with LLVM, I haven't implemented anything to do with the compiler yet. (Still deciding between LLVM and regular Assembly).