Skip to content

Comment on Function Arguments Are Not Function Colors

Comments

Actually, the IO monad in haskell desugars to

RealWorld -> (a, RealWorld)

Where RealWorld is a "token" that is just meant to be threaded through. You cannot create one yourself, so you have to be given one.

Thus, that function argument colors IO. Every PL feature is just an extension to System F.

As I said to another comment, this isn't a place for architecture astronautics or squinting until one thing looks like another. It's all assembler under the hood in the end and that language not only doesn't have color, it doesn't have types in any practical sense of the term. At the level of Haskell itself, IO is a color and IO is not a function argument. The compiled code is all assembler. The Haskell may itself be an interpreter for a language that has no color. Above it there is no color, below it it may be implementing something without colors, but at the level of Haskell itself, IO is a color.

In Bluefin, IOE (which allows you to do I/O, i.e. what Haskell's IO also allows you to do) is an argument, and therefore not a color under your interpretation.

https://hackage.haskell.org/package/bluefin-0.0.7.0/docs/Blu...

You mean under TFA's interpretation?

What's the difference?

Person you replied to said colour is language specific, not preserved by compilation (or decompilation), and I think you'd agree with that.

it is all assembly under the hood but it's also all lambda calculus under the hood

AboutSource Built by g1lg1l

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