Let's write a compiler, part 5: A code generator
briancallahan.net
Let's write a compiler, part 5: A code generator
1–10 of 32 posts
Re: Let's write a compiler, part 5: A code generator
#2This series of blogposts is amusing but it is kind of frustrating too: the end result is merely a compiler. It is a source to source translator from a source language which is very very similar to a subset of the target language. Well I guess you can call that a compiler, but it really doesn't teach the readers what an actual compiler looks like. Exaggerating a little, I would say that it feels like a few calls to sed could do the same thing using regexp.
Re: Let's write a compiler, part 5: A code generator
#3This series of blogposts is amusing but it is kind of frustrating too: the end result is merely a compiler. It is a source to source translator from a source language which is very very similar to a subset of the target language. Well I guess you can call that a compiler, but it really doesn't teach the readers what an actual compiler looks like. Exaggerating a little, I would say that it feels like a few calls to se…
It could not. Unless your language is regular class, then regular expressions cannot parse the language accurately.
Re: Let's write a compiler, part 5: A code generator
#4This series of blogposts is amusing but it is kind of frustrating too: the end result is merely a compiler. It is a source to source translator from a source language which is very very similar to a subset of the target language. Well I guess you can call that a compiler, but it really doesn't teach the readers what an actual compiler looks like. Exaggerating a little, I would say that it feels like a few calls to se…
C is his hammer, but tenure is tenure.
Re: Let's write a compiler, part 5: A code generator
#5This series of blogposts is amusing but it is kind of frustrating too: the end result is merely a compiler. It is a source to source translator from a source language which is very very similar to a subset of the target language. Well I guess you can call that a compiler, but it really doesn't teach the readers what an actual compiler looks like. Exaggerating a little, I would say that it feels like a few calls to se…
It could not. Unless your language is regular class, then regular expressions cannot parse the language accurately.
That's why I said "if feels like".
But nonetheless even if regexps would not be able to validate syntax, it does not mean that the source-to-source transformation could not be (mostly) achieved using them, because the source and target language are quite similar.
Imagine a new language exactly like C but every semicolon is replaced by a duck "\_o<". You could not parse it using regexps, but regexp could mostly "compile" it to C as it only requires to look for all "\_o<" to replace them with ";".
Re: Let's write a compiler, part 5: A code generator
#6Earlier quoted context omitted.
It could not. Unless your language is regular class, then regular expressions cannot parse the language accurately.
That's why I said "if feels like ". But nonetheless even if regexps would not be able to validate syntax, it does not mean that the source-to-source transformation could not be (mostly) achieved using them, because the source and target language are quite similar. Imagine a new language exactly like C but every semicolon is replaced by a duck "\_o<". You could not parse it using regexps, but regexp could mostly "comp…
This wouldn't work as you could have a semicolon in a string, to handle that you would need to know when you're in a string, and due to the existence of backslash escapable quotes in strings, you can't do that with a regex*
*A real Regular Expression. The extended versions with e.g backrefs can. But they're also Turing complete anyway
Re: Let's write a compiler, part 5: A code generator
#7Earlier quoted context omitted.
That's why I said "if feels like ". But nonetheless even if regexps would not be able to validate syntax, it does not mean that the source-to-source transformation could not be (mostly) achieved using them, because the source and target language are quite similar. Imagine a new language exactly like C but every semicolon is replaced by a duck "\_o<". You could not parse it using regexps, but regexp could mostly "comp…
This wouldn't work as you could have a semicolon in a string, to handle that you would need to know when you're in a string, and due to the existence of backslash escapable quotes in strings, you can't do that with a regex* *A real Regular Expression. The extended versions with e.g backrefs can. But they're also Turing complete anyway
I know that. But admit that it is nitpicking and completely besides the point.
Re: Let's write a compiler, part 5: A code generator
#8Hi all, I have a bit off topic question but seems related.
I'm trying to write sort of a SQL compiler. The current goal is to analyze queries and find similarities, later maybe to translate between sql dialects. I found Uber's QueryParser[1] but it's in haskell, so I started wrapping the python sqlparse[2] library and implement a Visitor to traverse their weird AST. 1. How close is it to implementing a compiler? 2. Is there theory you can suggest further reading for that matter? 3. Would you use a different language/library then I picked?
Thanks :)
[1] https://github.com/uber/queryparser [2] https://github.com/andialbrecht/sqlparse
Re: Let's write a compiler, part 5: A code generator
#9This series of blogposts is amusing but it is kind of frustrating too: the end result is merely a compiler. It is a source to source translator from a source language which is very very similar to a subset of the target language. Well I guess you can call that a compiler, but it really doesn't teach the readers what an actual compiler looks like. Exaggerating a little, I would say that it feels like a few calls to se…
Lots of compiler tutorials are like this - there's very little out there to explain how compilers really work.
This is my effort - trying to show genuine data structures and processes.
Re: Let's write a compiler, part 5: A code generator
#10Earlier quoted context omitted.
That's why I said "if feels like ". But nonetheless even if regexps would not be able to validate syntax, it does not mean that the source-to-source transformation could not be (mostly) achieved using them, because the source and target language are quite similar. Imagine a new language exactly like C but every semicolon is replaced by a duck "\_o<". You could not parse it using regexps, but regexp could mostly "comp…
This wouldn't work as you could have a semicolon in a string, to handle that you would need to know when you're in a string, and due to the existence of backslash escapable quotes in strings, you can't do that with a regex* *A real Regular Expression. The extended versions with e.g backrefs can. But they're also Turing complete anyway
Actually, I think that the grammar for a C string with escapes characters is regular. The only bit I am worried about are the back-slash octal and back-slash hexadecimal notations. But they are not relevant if you want to detect escaped quotes in strings.