Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

std vs. core #15

Open
adam-mcdaniel opened this issue Jul 29, 2020 · 4 comments
Open

std vs. core #15

adam-mcdaniel opened this issue Jul 29, 2020 · 4 comments
Labels
core library Related to Oak's core library error handling Related to Oak's error handling system hardening Improvement to the soundness of the project standard library Related to Oak's standard library

Comments

@adam-mcdaniel
Copy link
Owner

Right now, there is a bit of confusion about the distinction between the standard library and the core VM implementation.

The core VM implementation should be all that a program needs to compute anything. The compiler should NOT include functions for IO in the implementation of the core.

Each Target should implement a std_library method, which returns foreign code that implements the standard library.

@adam-mcdaniel adam-mcdaniel added the hardening Improvement to the soundness of the project label Jul 29, 2020
@kevinramharak
Copy link
Contributor

I would suggest to advise implementations to return a #[extern] directive? That should be enough for most implementations and keep the rust implementation clean.

@kevinramharak
Copy link
Contributor

An issue I am having with trying to seperate these is that the panic() feature currently writes output to 'stdout' on what goes wrong. Great for debugging but it depends on duplicate logic implemented in my standard library. What would be the spec for handling runtime errors?

@adam-mcdaniel
Copy link
Owner Author

Hmm, I hadn't considered how panic should be implemented. I think that panic info should be written to stdout for convenience sake, but I'm not really sure if there might be a better solution. On platforms that cant support stdout, they should just exit with an error return code, though.

I'm not really convinced of a specific idea yet; what do you think?

@kevinramharak
Copy link
Contributor

Well, I think most runtimes have some form of error reporting. That would be a great start. I think requiring it to exit with an error code fairly standard. Having a few documented exit codes also seems like a good idea. Making it optional (but best practice) to write a human readable message to stderr (or stdout if there is no stderr) seems like a sane thing to do for now. That would leave room for debugging tools to give as much info as possible once those are introduced. I'm asking because having a standardized way of dealing with runtime errors seems like a smart thing to do when targeting as much environments as possible.

@adam-mcdaniel adam-mcdaniel added core library Related to Oak's core library standard library Related to Oak's standard library error handling Related to Oak's error handling system labels Aug 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core library Related to Oak's core library error handling Related to Oak's error handling system hardening Improvement to the soundness of the project standard library Related to Oak's standard library
Projects
None yet
Development

No branches or pull requests

2 participants