
Simple Tiny Compiler in C - zakirullin
https://github.com/zakirullin/tiny-compiler
======
vajrabum
The structure of that program looks kinda weird with .h files but no matching
.c files. Instead all the code is in the .h files.

~~~
saagarjha
Since there's only one object file and header guards, this ends up working
out.

~~~
zakirullin
Indeed there's only one object file with header-guards. It's not intended to
be used as a library or something. Moreover - the codebase is really tiny.
That being said - it made with simplicity in mind

~~~
RealityVoid
Sure, but... wouldn't it have been simpler to have the functions in the .c
file?

This is just a odd way of doing things. There are good reasons you don't
usually see this, add one more .c file and things get awkward real fast.

Sure, it works in this particular instance, but it just makes me feel itchy.
Maybe it's past trauma where I saw real weird codebases with static functions
in .h files used across multiple .c files. It was just horrible to work with
and reason about.

~~~
zakirullin
Well if there are already two remarks on that matter - I'll fix the issue! I
know the profits, yeah. Things haven't exactly worked out the way I thought
they would - there should be a border between simplicity/bad design.

Hahah, yeah it smells, can't argue with that. I believe that everyone had a
trauma like that in the past :)

~~~
sjamaan
Maybe it would make more sense if you used only .c files; people typically
expect only prototypes, type definitions, macros and so on in .h files.

Including one .c file in another is a bit odd, but less surprising. But then
having include guards makes the entire thing a bit weird :)

~~~
zakirullin
Haha. Yup, I know that, of course. And I have never used that practice in real
world projects. Well, I'll put both _.c /_.h files, that doesn't add that much
overhead.

------
feintruled
Nice job. Read the first couple of entries, look forward to following through
the rest. I enjoy this kind of exercise, just complex enough to give you a
flavour of how the 'real' thing works whilst not being a mere toy example.

~~~
zakirullin
Liked your description, thanks!

------
krychu
Great exercise indeed. Why the choice of LL over LR parsing? I thought the
latter one was a more common choice for implementing languages?

~~~
userbinator
Recursive-descent which is LL is very common for parsing because of its
simplicity; LR is theoretically more powerful, but in practice there doesn't
seem to have been any great need for it. GCC, Clang/LLVM, MSVC, javac, csc
(the C# one), and a whole bunch of other compilers use RD (often with some
sort of precedence-climbing, which is essentially a refactoring of RD). GCC
was originally using a generated LR parser (Bison) but moved to RD a long time
ago.

