Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a C compiler in 500 lines of Python (2023)

vgel.me

Post reply on HN
Print view View original

111–114 of 114 posts

Re: Writing a C compiler in 500 lines of Python (2023)

#111

Post by sevensor »

kragen wrote: post #110
sevensor wrote: post #109

Earlier quoted context omitted.

Ah, I see. I’ve written that code where you have to add one case to a whole bunch of pattern matches. It’s not terrible; I rather like that everything that does the same thing is in the same place. But I have wondered if there was a better way. Clearly I need to go read the article again.

Yeah, I share your assessment that it's not unmanageable. But it does add friction. I suspect that there are only two real solutions: - program source code that isn't a linear document but instead can be viewed in multiple different ways: by operation or by operand type, for example. Then you would use the view that best suits the modification you were doing at the time. Smalltalk, for example, does support browsing…

> Smalltalk, for example, does support browsing either all the implementors of a method selector or all the methods of a class

That’s pretty neat. I tried using the object browser a million years ago and it confused me, but I didn’t know anything about anything at the time. Maybe Smalltalk deserves another look.

Re: Writing a C compiler in 500 lines of Python (2023)

#112

Post by jlokier »

bluGill wrote: post #81
jlokier wrote: post #73

Earlier quoted context omitted.

If you can search (and do other operations) on a linked list, and the lists are long enough to matter, you can trivially speed it up to a fixed-size hash table with hardly any code changes. This: entry = list_search(key, list); becomes: entry = list_search(key, lists[hash(key) % (sizeof(lists)/sizeof(lists[0]))]); This: list_add(key, entry, list); becomes: list_add(key, entry, lists[hash(key) % (sizeof(lists)/sizeof(…

Those would be useful optimizations once the simplest thing works. However the goal here is 500 lines- not fast, correct, maintainable code. If I was to write this for real world use I wouldn't start with C in the first place.

That's why I described a not very well known trick that requires just +1 line, the definition of hash(). It's neither fast nor maintainable, it's just a neat hack that gives you some of the performance of hash tables for negligible source code overhead. Perfect for tiny, self-contained programs like this one.

Re: Writing a C compiler in 500 lines of Python (2023)

#113

Post by igouy »

sevensor wrote: post #111
kragen wrote: post #110

Earlier quoted context omitted.

Yeah, I share your assessment that it's not unmanageable. But it does add friction. I suspect that there are only two real solutions: - program source code that isn't a linear document but instead can be viewed in multiple different ways: by operation or by operand type, for example. Then you would use the view that best suits the modification you were doing at the time. Smalltalk, for example, does support browsing…

> Smalltalk, for example, does support browsing either all the implementors of a method selector or all the methods of a class That’s pretty neat. I tried using the object browser a million years ago and it confused me, but I didn’t know anything about anything at the time. Maybe Smalltalk deserves another look.

Smalltalk IDEs are usually multi-window, so it isn't either/or, it's by method selector and by class instance methods and by …

Re: Writing a C compiler in 500 lines of Python (2023)

#114

Post by fuzztester »

pjmlp wrote: post #97
fuzztester wrote: post #94

Earlier quoted context omitted.

Doesn't matter where it came from - in the context of my previous comment. I was talking w.r.t. the earlier version of C, and not in connection with C++.

It does from historical purposes, how the C standard came to be, what are the decisions that turned K&R C into C89.

Okay, I get it now.
Post reply on HN