This looks a lot like the Tiny Pascal compiler that BYTE published a listing of back in 1978. http://www.trs-80.org/tiny-pascal/ I figured out the basics of how a compiler works by going through it line by line.
[deleted]
Writing a C compiler in 500 lines of Python
121–130 of 183 posts
Re: Writing a C compiler in 500 lines of Python
#122So, given the python is an interpreter and very well understood, can we say that we are sure this compiler does not include Thompson virus?
[deleted]
Re: Writing a C compiler in 500 lines of Python
#123Earlier 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.
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.
DSLs are awesome for what they are. DSLs let you ingest/load untrusted user code directly and have strong isolation barrier, allowing for very powerful user customizations with "native" implementations of certain features /functions.
Anything from programmable authorization to custom views becomes safely and relatively easily available. Say what you want about ESB pattern, but you can implement ESB transformers in a custom DSL.
Obviously not every piece of software needs these features, but when it does DSLs are very handy.
Re: Writing a C compiler in 500 lines of Python
#124Somewhat unrelated question, but I think one of the second most difficult things of learning C for coders who are used to scripting languages is to get your head around how the various scaler data types like short, int, long,... (and the unsigned/hex version of each) are represented and how they relate to each other and how they relate to the platform.
I am wondering if this complexity exists due to historical reasons, in other words if you were to invent C today you would just define int as always being 32, long as 64 and provide much more sane and well-defined rules on how the various datatypes relate to each other, without losing anything of what makes C a popular low-level language?
Re: Writing a C compiler in 500 lines of Python
#125Somewhat unrelated question, but I think one of the second most difficult things of learning C for coders who are used to scripting languages is to get your head around how the various scaler data types like short, int, long,... (and the unsigned/hex version of each) are represented and how they relate to each other and how they relate to the platform. I am wondering if this complexity exists due to historical reason…
If we were to write C today, we would never have such cases.
Re: Writing a C compiler in 500 lines of Python
#126Earlier quoted context omitted.
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.
I'm wondering, is Bash/Shell a DSL? You can do anything with it because it allows launching other programs, but I'd say it was designed specifically for the domain of launching other programs and building data pipelines with their in- and outputs.
While DSLs are primarily designed to easily express certain idioms (e.g. Logo-family primarily describes pencil movement), generally (!), DSL is embeddable, isolated, Turing incomplete language. Although some DSLs are Turing complete, they are first and foremost designed to express domain specific idioms.
IMO Bash and friends are too powerful and generic to be considered DSLs.
Re: Writing a C compiler in 500 lines of Python
#127Somewhat unrelated question, but I think one of the second most difficult things of learning C for coders who are used to scripting languages is to get your head around how the various scaler data types like short, int, long,... (and the unsigned/hex version of each) are represented and how they relate to each other and how they relate to the platform. I am wondering if this complexity exists due to historical reason…
I learnt C about a decade ago (after using scriping languages 10 years prior) and just stuck with using the uint values, no second thoughts about how big a uint32_t is.
Re: Writing a C compiler in 500 lines of Python
#128Somewhat unrelated question, but I think one of the second most difficult things of learning C for coders who are used to scripting languages is to get your head around how the various scaler data types like short, int, long,... (and the unsigned/hex version of each) are represented and how they relate to each other and how they relate to the platform. I am wondering if this complexity exists due to historical reason…
>if you were to invent C today you would just define int as always being 32, long as 64 and provide much more sane and well-defined rules on how the various datatypes relate to each other, without losing anything of what makes C a popular low-level language?
You'd lose something because those decisions would be impractical for 8-bit and 16-bit targets (which still exist in the world of embedded programming).
Re: Writing a C compiler in 500 lines of Python
#129Somewhat unrelated question, but I think one of the second most difficult things of learning C for coders who are used to scripting languages is to get your head around how the various scaler data types like short, int, long,... (and the unsigned/hex version of each) are represented and how they relate to each other and how they relate to the platform. I am wondering if this complexity exists due to historical reason…
>if you were to invent C today you would just define int as always being 32, long as 64 and provide much more sane and well-defined rules on how the various datatypes relate to each other, without losing anything of what makes C a popular low-level language? You'd lose something because those decisions would be impractical for 8-bit and 16-bit targets (which still exist in the world of embedded programming).
Would it be possible to create two versions of the language: microC for embedded C programs where these decisions matter, and standard C for PC/servers which basically all use the same representation for these scalers?
My main point is that a C programmer today is forced to learn dozens of rules just to cater for many niche platforms that they will probably never target, so if you were to separate those two use cases you can get a much more neat C that targets modern 64 bit architectures with all the power of traditional C but a bit less portability.
Re: Writing a C compiler in 500 lines of Python
#130Somewhat unrelated question, but I think one of the second most difficult things of learning C for coders who are used to scripting languages is to get your head around how the various scaler data types like short, int, long,... (and the unsigned/hex version of each) are represented and how they relate to each other and how they relate to the platform. I am wondering if this complexity exists due to historical reason…
>if you were to invent C today you would just define int as always being 32, long as 64 and provide much more sane and well-defined rules on how the various datatypes relate to each other, without losing anything of what makes C a popular low-level language? You'd lose something because those decisions would be impractical for 8-bit and 16-bit targets (which still exist in the world of embedded programming).
In fact, the default integer promotions together with the requirement that unsigned int hold numbers until at least 2^16 is the main reason C code for 8-bitters is somewhat... stylized, to put it mildly.