
Compiling a Functional Language Using C++, Part 9 – Garbage Collection - pcr910303
https://danilafe.com/blog/09_compiler_garbage_collection/
======
blackandblue
is there a "cpp: the good parts" book that anyone can recommend for someone
who has done c/cpp a long time ago?

~~~
cannam
Bjarne Stroustrup's "A Tour of C++"
([http://www.stroustrup.com/Tour.html](http://www.stroustrup.com/Tour.html))
is close. It's a slim volume that is roughly a survey of the language as if it
had begun with C++11.

~~~
colejohnson66
I wish he’d update them (both books) for C++20 (C++2a), or even just C++17.

~~~
steerablesafe
A Tour of C++ 2nd edition covers C++17, AFAIK.

~~~
pjmlp
Yes it does and also mentions parts of C++20 like concepts and modules.

------
LessDmesg
These blog posts are golden, thanks. I definitely will peruse them when
creating my language.

------
jakearmitage
Does anyone know anything like this, but for an indentation-based language?
Writing a Python-like parser was always hard for me, ending up with a generic
INDENT/DEDENT counter mess.

~~~
gnulinux
You need to use the "lexer trick". While lexing your input data, instead of
ignoring whitespace or producing token WS or TAB or whatever, keep track of
your indents and newlines. Then it's simple to decide if it's an indent
(newline followed by at least 1 more space or tab than previous, add this to
your indents stack) or dedent (newline followed by the previous indent (look
at your indent stack)). Then produce INDENT and DEDENT _seperate_ tokens. Once
you have these tokens produced by tokenizer, it's easy to parse. Do the usual
recursive descent. Source: I built my own python compiler (python->C++) as a
university projects.

~~~
tomp
Pretty much this. You need a stack because an single NEWLINE might result in 2
DEDENT tokens:

    
    
        if x:
          if y:
            f()
        g()
    

You only need to keep track of whitespace (spaces and/or tabs) after a newline
(and you can skip lines with only whitespace & comments). It's also useful to
keep tracks of delimiters (like parentheses and brackets), if you want to
ignore newlines/indents inside expressions (like Python).

The easiest IMO is writing a lexer using a lexer generator (Lex, Flex, ...)
and outputting a NEWLINE(spaces) tokens, then have another class that keeps
track of indents, parentheses, etc.

I wrote a lexer/parser combo that (1) tracks whitespace in top (file) context,
(2) ignores whitespace in expressions (parentheses, [] arrays, {} records),
except (3) _restarts_ indentation-tracking in _{} blocks_ (even if they're in
parentheses themselves!) - now _that 's_ hard to code (and debug LOL).

