[AnimalMuppet]

Do you think Haskell recognizes the physical reality of the machine more than C does? If so, how specifically does it do so?

[kqr]

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]

I 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.

[dllthomas]

There might be a cleaner way of doing it, but

    do
      let ptr :: Ptr Word32 = nullPtr `plusPtr` 0xF00BA4
      poke ptr 0x0102ABCD

should have you covered.

[tome]

> C lets me actually control the whole machine

Really? Can you run micro-ops?

[yakshaving_jgt]

You 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.