Skip to content

Comment on Pedagogical Downsides of Haskellparent

Comments

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

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.

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.

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.
C lets me actually control the whole machine

Really? Can you run micro-ops?

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.