5 ms·
This 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 la
by p4bl0 5y ago
This 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.
- chrisseaton 5y agoLots 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. https://github.com/chrisseaton/rhizome https://github.com/chrisseaton/rhizome
- divtiwari 5y agoHey, I just skimmed through this, it seems to be brilliant!! Just one question, can one go through this tutorial without much knowledge about Ruby? Should one read it with 'Ruby Under a Microscope'? I have a decent enough knowledge about compilers, have gone through Thorsten Ball's, 'Writing an Interpreter in Go'.
- chrisseaton 5y agoOnly need to know basic Ruby programming - no libraries or deep knowledge. But the project is unfinished I’m afraid - you will find dead-ends.
- divtiwari 5y agoOh I see, thanks for the info!! I'll see what I can gain out of it. Thanks once again for the info!!
- junon 5y agoIt could not. Unless your language is regular class, then regular expressions cannot parse the language accurately.
- im3w1l 5y agoYou can build a parser around regexes though, where most of the code is regexes and then you have a little bit of code to deal with the irregularity. For instance consider arithmethic expressions consisting of constants, -, +, *, /, and parentheses. You could evaluate that using something like (expression to parse a numeral is left as exercise to reader). while expression is not a numeral replace all "\((NUMERAL)\)" with first group if find first "(NUMERAL)([*/])(NUMERAL)" replace with result else if find first "(NUMERAL)([+-])(NUMERAL)" replace with result
- ashton314 5y agoWhat you are doing there is conflating the lexing phase and the parsing phase. Regexes are perfect for recognizing tokens, but for a language with nested parentheses, you must have a push-down automaton to process it. Otherwise, you will not be able to verify that your delimiters are matched.
- im3w1l 5y agoThat's one way of looking at it I suppose. But it does require stretching the definition of token a little bit if you are eg using regexes to identify arbitrarily long multiplications. I think my prefered perspective is that you are using regexes to parse regular sublanguages and then something more powerful (e.g. a push down automaton, but there are even more powerful parsers than that) to bind those sub-parsers together.
- p4bl0 5y agoThat'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 ";".
- peepholeoptim 5y agoC is his hammer, but tenure is tenure.