not to mention the fact that it was a lang specifically to suit one person's tastes, and then a whole cult formed around it for some reason, obsessed with the idea that it could replace all other code forever (or maybe just c(++))
Often there will be multiple layers of transformation from the initial parse tree to the final result, so it might not be "execute" straight away, for example if you are going to build a compiler and you need to lower the semantics of the input language to generate machine code. For an initial interpreter, whatever is the easiest way for you to get something to happen within the structure will be good
so if I had an AST node type for floats, and one for strings, and I wanted to have a type/union/class/whatever that encompasses all AST node types that return a value via, say, a member function, how would I say "idk the return type of the member function, but it does return a thing"?
and would I use a template? a union? some other random thing?
Exposing the RealWorld in IO still gives you getUnsafePerformIO :: IO (IO a -> a) which is just as bad as unsafePerformIO.
IO uses unlifted types (RealWorld#, (#,#)) to avoid unnecessary allocations, so it doesn't exactly match State anyway.
It does match ST, but a direct definition of IO mini...
> getUnsafePerformIO :: IO (IO a -> a)
This is why Haskell doesn't expose main like Python does.
if I'm separating chunks of code for my program, but the things I'm importing to main aren't intended to be used anywhere else, can I just import it directly without a header file?
@blueberry so if multiple modular chunks need each others' content, how would I handle that? just import everything everywhere and use header guards to clean up my mess?
Slavic languages have a fluid sentence structure, and OSV is often used (myself included) if you want to emphasize the object (although IME OVS is more often used for that)