[flagged]
[deleted]
Writing a C compiler in 500 lines of Python
91–100 of 183 posts
Re: Writing a C compiler in 500 lines of Python
#92Earlier quoted context omitted.
> And somehow I have ended up with a very strong bias against DSLs. Most DSLs are bad, partially because most people are bad at designing languages. Embedded DSLs can be quite neat. Eg Haskell makes it easy to embed something like DSLs inside your Haskell code. (If you squint a bit, the ability to define your own functions in any language goes in that direction of allowing you to define your own mini-sub-language tha…
I don't necessarily think the DSLs are badly designed. But personally I find the overhead in learning and remembering a new language to be enormous. I instantly drop from extremely high productivity in my language of choice to fumbling around like a newbie. And often DSLs are used for smallish tasks that you work on, write the code, then leave for a long time. Then you come back to it and have no idea how that langua…
Embedded DSLs have much lower learning overhead, since they are just embedded in the language you are already using. Eg in Haskell, they are still valid Haskell programs. So they eg inherit the control structures from the host language, and most of the tooling in your editor, like 'jump to definition' also still works.
See http://wiki.haskell.org/Embedded_domain_specific_language
Because the overheads are lower, the payoff doesn't have to be as high to make it worthwhile.
(However, there's still some overhead, otherwise you wouldn't really label them as embedded-DSLs.)
Re: Writing a C compiler in 500 lines of Python
#93> Instead, we'll be single-pass: code generation happens during parsing IIRC, C was specifically designed to allow single-pass compilation, right? I.e. in many languages you don't know what needs to be output without parsing the full AST, but in C, syntax directly implies semantics. I think I remember hearing this was because early computers couldn't necessarily fit the AST for an entire code file in memory at once
Linked from another thread: http://cm.bell-labs.co/who/dmr/chist.html It explains the memory limits and what happened :) > After the TMG version of B was working, Thompson rewrote B in itself (a bootstrapping step). During development, he continually struggled against memory limitations: each language addition inflated the compiler so it could barely fit, but each rewrite taking advantage of the feature reduced its s…
Infix parsing chews up a remarkable amount code and memory.
It's scary just how much easier it is to parse languages without infix parsing.
Re: Writing a C compiler in 500 lines of Python
#94Earlier quoted context omitted.
I don't necessarily think the DSLs are badly designed. But personally I find the overhead in learning and remembering a new language to be enormous. I instantly drop from extremely high productivity in my language of choice to fumbling around like a newbie. And often DSLs are used for smallish tasks that you work on, write the code, then leave for a long time. Then you come back to it and have no idea how that langua…
Embedded DSLs have much lower learning overhead, since they are just embedded in the language you are already using. Eg in Haskell, they are still valid Haskell programs. So they eg inherit the control structures from the host language, and most of the tooling in your editor, like 'jump to definition' also still works. See http://wiki.haskell.org/Embedded_domain_specific_language Because the overheads are lower, the…
I wasn't really aware of the embedded DSL distinction.
But even then. I was never really able to get into Observable because although it looks like JavaScript, there are kind of hidden objects and methods available to you that I found weirdly hard to discover.
Re: Writing a C compiler in 500 lines of Python
#95Writing your own compiler - demystifies compilers, interpreters, linkers/loaders and related systems software, which you now understand. This understanding will no doubt one day help in your debugging efforts; - elevates you to become a higher level developer: you are now a tool smith who can make their own language if needed (e.g. to create domain specific languages embedded in larger systems you architect). So cong…
I dunno. I did a compiler writing course once, writing a compiler for a subset of Pascal in Ada, generating a kind of quasi assembly. It was a team project. I did most of the codegen and static optimisation. It was super fun and interesting. But I wouldn't say it was a terribly useful exercise that has greatly enriched me as a programmer. And somehow I have ended up with a very strong bias against DSLs.
Yeah, nowadays a DSL is almost never a good idea. A library for some pre-existing flexible language can do the job without reinventing a whole lot of wheels. The most specific languages I can think of that make sense are SQL and Solidity.
But DSLs are tempting, especially among the more passionate programmers, so at work we've ended up with a lot of them. All of them are tripping hazards.
Re: Writing a C compiler in 500 lines of Python
#96[flagged]
The new Detect UB instruction is great.
Re: Writing a C compiler in 500 lines of Python
#97Earlier quoted context omitted.
I think Borland’s Turbo Pascal was also a single pass compiler that emitted machine code as COM files.
Surely it is a feature of all Pascal compilers that they are single pass. I thought that it was part of the specification of the language that it be possible to compile in a single pass.
It's disturbing to me that I remembered this, but the IBM Pascal Compiler for DOS (1981) had two passes.
https://winworldpc.com/product/ibm-pascal-compiler/100
Re: Writing a C compiler in 500 lines of Python
#98It is interesting to think that 500 lines of code is something one can write in one or two days. But, writing a C compiler in 500 of comprehensible code (even in python) is challenge in itself that may take months after a few years of solid learning. I wonder if is this a good path to becoming an extremely productive developer. If some one spends time developing projects like this, but for different areas... A kernel…
You might like the book 500 Lines or Less, Experienced Programmers solve interesting problems
https://www.amazon.com/500-Lines-Less-Amy-Brown/dp/132987127...
Re: Writing a C compiler in 500 lines of Python
#99Earlier quoted context omitted.
I dunno. I did a compiler writing course once, writing a compiler for a subset of Pascal in Ada, generating a kind of quasi assembly. It was a team project. I did most of the codegen and static optimisation. It was super fun and interesting. But I wouldn't say it was a terribly useful exercise that has greatly enriched me as a programmer. And somehow I have ended up with a very strong bias against DSLs.
> And somehow I have ended up with a very strong bias against DSLs. Most DSLs are bad, partially because most people are bad at designing languages. Embedded DSLs can be quite neat. Eg Haskell makes it easy to embed something like DSLs inside your Haskell code. (If you squint a bit, the ability to define your own functions in any language goes in that direction of allowing you to define your own mini-sub-language tha…
> Most DSLs are bad, partially because most people are bad at designing languages.
A perfectly-designed DSL is still bad just because it's a whole 'nother language for you to build, and for others to learn, that probably isn't needed for whatever project.
Re: Writing a C compiler in 500 lines of Python
#100Writing your own compiler - demystifies compilers, interpreters, linkers/loaders and related systems software, which you now understand. This understanding will no doubt one day help in your debugging efforts; - elevates you to become a higher level developer: you are now a tool smith who can make their own language if needed (e.g. to create domain specific languages embedded in larger systems you architect). So cong…
I dunno. I did a compiler writing course once, writing a compiler for a subset of Pascal in Ada, generating a kind of quasi assembly. It was a team project. I did most of the codegen and static optimisation. It was super fun and interesting. But I wouldn't say it was a terribly useful exercise that has greatly enriched me as a programmer. And somehow I have ended up with a very strong bias against DSLs.
I thought the same when i did compiler course, but 8 years after that course i wrote tooling to mass refactor a java codebase by creating AST manipulate AST and convert the AST to code again.