Handling Runtime Code

[kiljacken]

@MovingtoMars said the following on IRC before I could ask him about it:

having the runtime stuff in the parser package isn't going to work

So I'm creating this issue both so I can ask him to explain why, and to discuss how to handle the runtime code in the future.

As he hinted at, the runtime code is currently stored in runtime.go in the parser package, which I know isn't optimal due to our package structure. Fx we can't do semantic checks on the runtime code atm because there is a dependency between the semantic checks and the parser, and thus we can't include the semantic checks in the parser.

Among changes that would alleviate this would be extracting the AST and the type system from the parser package to their own individual packages.

[MovingtoMars]

Ideally it would be package std::runtime that gets imported into the global namespace automatically, for things like Option<T> and Result<T>. string and rune can just be specified in the compiler, since they're used as types for literals.

[kiljacken]

string and rune can just be specified in the compiler, since they're used as types for literals.'

there's no real need to do this though.

Also, I'm not sure if you've seen but I've moved loading the runtime module to cmd/ark, which should resolve any problems you might've found.

The main thing is how to handle locating the runtime (or even stdlib in general) without always having the user pass along the full path. If we ever plan to distribute ark via various package managers, we'd need a plan for this.

[MovingtoMars]

string and rune can just be specified in the compiler, since they're used as types for literals.'

there's no real need to do this though.

I did this when moving Option to the runtime, because expect uses a string literal, so we had to have the string type already.

[kiljacken]

👍 makes sense now that I see the purpose