I don't see he use match case... while it's clearly a good use case.
Writing a C compiler in 500 lines of Python
141–150 of 183 posts
Re: Writing a C compiler in 500 lines of Python
#142I wrote a C compiler back in the day as a learning exercise. It was the most fun and rewarding project.
Re: Writing a C compiler in 500 lines of Python
#143Earlier quoted context omitted.
at the very least it'll remove a lot of 'magic' from programming. Today a lot of people seem to be not so fond of university education but I'm personally very glad it made me go through implementing a shell, a compiler, a little toy kernel and so on. The feeling that you write code somewhere in the skies and have no idea how something works underneath has always really bugged me when I've used something.
You don't need a university education to do those things, just some curiosity. The function of the university in the near future will probably just be to have like-minded curious people to discuss ideas with, and to get a better grasp of what problems need to be solved (specifically scientific ideas, rather than just applying engineering). The prestige element (specifically of certain universities over others, perhap…
> You don't need a university education to do those things, just some curiosity.
The same is true of any field. Medicine for example. Then again I have several acres of swamp behind my place to help me when lerning from my mistakes.
Re: Writing a C compiler in 500 lines of Python
#144I have to wonder if there's a Scheme to WASM compiler out there someplace right now I haven't found yet.
Have you seen Guile Hoot?
Re: Writing a C compiler in 500 lines of Python
#145Somewhat 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.
Explicit variable size is useful for limited memory space envs like microcontrollers.
Re: Writing a C compiler in 500 lines of Python
#146Earlier quoted context omitted.
>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).
If you’re writing code for those why not just use the smaller data types if you don’t need bigger ones? That way it will work efficiently on both and the behaviour will be consistent
Fair point. I guess the issue is with library code that uses int. But you aren't typically going to use lots of general-purpose library code if you're targeting a microcontroller.
Re: Writing a C compiler in 500 lines of Python
#147Earlier quoted context omitted.
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.
I think that's actually an interesting example of how C sees itself as a high level language (from the perspective of the early 70s), even though we now categorize it as low-level. You'd expect the default integer type in a high level language to be able to store values that are large enough for an interesting range of practical tasks; 16 bits is arguably the bare minimum to meet that requirement.
IIRC a retrospective by one of the designers listed the default promotions as a careless mistake, because the original—offhand—reasoning was that the registers are 16-bit anyway, so they might as well widen everything when it’s free (on the only machine the language was implemented on at that moment).
Re: Writing a C compiler in 500 lines of Python
#148Somewhat 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…
The int was supposed to be the native word size. So 16-bit on 286 and earlier, 32-bit on 386 and later, and 64-bit on x64. Except, of course, int has been 32 bits for so long on x86 (which has been the single most important ISA for just as long), and short was 16-bit for even longer that moving to 64-bit-wide int and 32-bit-wide short (which is what x64 naturally suited for) was just impossible, so it didn't happen, we're stuck with LP64 (on Linux) and LLP64 (on Windows) data models.
Re: Writing a C compiler in 500 lines of Python
#149Earlier quoted context omitted.
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.
What's 'Observable'?
Re: Writing a C compiler in 500 lines of Python
#150Earlier 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…
> 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.
I don't know. Eg people seem perfectly happy to use regular expressions for matching text, instead of accessing the same functionality via eg regular functions in their favourite language.