3 ms·
Technically, within the language, yes. C itself simply delegates a lot of logic to the "physical machine"[1] by leaving it unspecified or implementation-defined
by kqr 4y ago
Technically, within the language, yes. C itself simply delegates a lot of logic to the "physical machine"[1] by leaving it unspecified or implementation-defined. In contrast, Haskell actually tries to model these differences within the type system and standard libraries, with IORefs, STMs, and whathaveyou.
(In fact, I just checked the IORef documentation and it actually references the x86/64 architecture manual to explain some of the behaviour that can be expected. I would be surprised if any part of the C standard did that.)
[1]: I mean, if we're using an x86 derivative we're still talking about a very fancy PDP-11 emulator.
- AnimalMuppet 4y agoI see. The language spec explicitly talks about the machine. That's not nothing. In practice, though, when I have some piece of memory-mapped hardware attached, and I want to talk to it, in C I can say: *(uint32_t*)0xF00BA4 = 0x0102ABCD; or whatever I need to flip the bits. C lets me actually control the whole machine. Whereas Haskell... I don't know, but I suspect it lets me actually use the physical machine a lot less.
- tome 4y ago> C lets me actually control the whole machine Really? Can you run micro-ops?
- yakshaving_jgt 4y agoYou know you can write C inside Haskell, right? Like, there's literally nothing stopping you. You can use FFI, and you can also write C inline. You can have the best of both, if you want.
- dllthomas 4y agoThere might be a cleaner way of doing it, but do let ptr :: Ptr Word32 = nullPtr `plusPtr` 0xF00BA4 poke ptr 0x0102ABCD should have you covered.