Live data from Hacker News

The Super Tiny Compiler

github.com

31–40 of 44 posts

Re: The Super Tiny Compiler

#31
post #16

Earlier quoted context omitted.

Some compilers tokenize while parsing, but for a different reason: it's faster and uses less memory to generate the AST (and sometimes even do analyses) while you're reading the input than to allocate and store a giant list of tokens and then parse that. Most compilers try not to fail when they encounter a syntax error, they try to "recover" and parse the remaining document, usually starting from the next valid state…

> Some compilers tokenize while parsing, but for a different reason: it's faster and uses less memory Rather legit reasons.. The one I'm writing does this. It seems akin to natural language processing. You'd interrupt a speaker early if you can't make sense of his uttering. > Most compilers try not to fail when they encounter a syntax error, they try to "recover" and parse the remaining document This seems ardous for…

"> It seems akin to natural language processing. You'd interrupt a speaker early if you can't make sense of his uttering."

But if you're reading a book and can't understand a sentence, you'll probably glance at the rest of the page to see if there are clues in the context.

Maybe it's a printing error and a paragraph has been repeated. A human who sees the entire page will detect that problem immediately and simply skip over the repeated paragraph. A computer that gives up at the first sight of incongruency has no idea that recovery was so easy.

The analogy here might be relevant to error messages. A compiler that "sees the whole page" can potentially offer more useful suggestions to the programmer about how to fix a problem.

Re: The Super Tiny Compiler

#32

it wasn't clear at all from a 5 second skim of the code and looking at the readme what the source and targets were

* We're going to compile some lisp-like function calls into some C-like * function calls. From the top of the source file.

That's on lines 83/84. I'm not entirely sure that qualifies as the "top" of the source file. It's on the 4th page of the source file, given a traditional 80x25 terminal. (Assuming no wrapping, which the ascii art banner definitely could. A lot.)

Re: The Super Tiny Compiler

#33
Lots of tiny, self-hosting compilers here: http://t3x.org

For example:

Compiler for a procedural language, compiling to binary in 1500 lines: http://t3x.org/t3x/comp.html

Super-portable tiny compiler for DOS, CP/M, Unix, and a VM: http://t3x.org/t3x/index.html#0

Self-hosting LISP compiler in 400 lines: http://t3x.org/lfn/liscmp.lisp.html

Re: The Super Tiny Compiler

#36
post #6
post #5

Question to compiler writers : when is it useful, if ever, to tokenize the whole input beforehand (as done here) ? You wouldn't catch an early syntax error and would go on tokenizing till the end for nothing.

I think most programming languages tokenize first. Tokenizing is absurdly fast, like 100x faster than printing to a terminal.

> Tokenizing is absurdly fast

is rather a very good reason to interleave tokenizing and parsing. Otherwise your tokenizer will just get stuck in iowait for no good reason.

Re: The Super Tiny Compiler

#37
post #14

Earlier quoted context omitted.

Wrote a C-subset compiler for a compilers course back in university. In general it's useful for a compiler to not just hit the first error it can find in the source code and immediately error out. Instead, if you keep parsing after encountering an error, you can often encounter more errors, so that you can give the user a list of errors they need to fix, not just the first one. In that sense, a compiler's job isn't o…

I'm struggling with this idea. You could end up tokenizing the inside of an unopened string literal for (contrived) ex : String s = hello world"; [-> typename:'String' id's' op'=' id'hello' id'world' ...] And it would cascade if then foo("blah"); (...) [-> strlit';\nfoo(' id'blah' ...] A parser-first approach will stop with unknown id 'hello' and avoid the cascade.

Check out this section of Crafting Interpreters on Error Recovery: https://craftinginterpreters.com/parsing-expressions.html#pa...

Re: The Super Tiny Compiler

#38

> * We're going to compile some lisp-like function calls into some C-like > * function calls. Isn't this a transpiler, doing mostly string replacement?

It still has to separate tokens, understand a nested structure, and output a different format. It's a small compiler, but is a compiler, and honestly understanding parsers can help a lot with text processing tasks.

Re: The Super Tiny Compiler

#39
post #5

Question to compiler writers : when is it useful, if ever, to tokenize the whole input beforehand (as done here) ? You wouldn't catch an early syntax error and would go on tokenizing till the end for nothing.

I am a pro compiler writer and I always use scanner-less parsers (no tokens). It allows me to change how tokens are interpreted on the fly. Very useful for the kind of problems I work on.

Re: The Super Tiny Compiler

#40
post #29
post #5

Question to compiler writers : when is it useful, if ever, to tokenize the whole input beforehand (as done here) ? You wouldn't catch an early syntax error and would go on tokenizing till the end for nothing.

For the year 1970 and after: never. This should always be part of the parser for reasons of being confidently correct. Thinking otherwise just leads to suffering. The problem with tutorials like Tiny Compiler or Crafting Interpreters is that the authors do not run into problems with the code shown in their teaching materials, but as soon as a student wants to apply it to modestly complex grammars, it stops working. T…

I am a professional compiler writer and nope you are wrong. I never tokenise everything up front and instead read tokens on demand. It is much faster and enables me to change how tokens are interpreted on the fly. Which enables me to parse different languages with different token definitions in the same file. Something that I need for the production work I do.
Post reply on HN