PROS 4 Main Discussion and Planning

[WillXuCodes]

Hey Folks,

We've been planning our roadmap for how we want to go about working the kernel into its PROS 4 form. Here's a general outline of our plans:

https://drive.google.com/file/d/1XcrE97G7Fm6GN-kjT6ok3h1rQyg6L0HO/view?usp=sharing

• The PROS Development Team

[nickmertin]

Looks like a good plan to me. One other idea that I think should be in there (please correct me if this is already covered under anything currently listed) is removing sentinel values for errors (or any other purpose, though I think they're only used for errors currently), to make it easier to avoid common classes of bugs. There are a number of ways to do this: in C, it could be return-by-pointer with the actual return value being the success/failure result, or it could return a struct; in C++, a more idiomatic solution could be provded. This is quite in line with, for example, what is done commonly in Rust (including in vex-rt).

I know this has been discussed informally with @HotelCalifornia , but unfortunately it looks like I never got around to making an issue or drafting a proper RFC.

[nickmertin]

I believe targeting C++17 or later is on the table. I do like the idea of wrapping it with a class that provides a cleaner interface; std::variant is great, but not very ergonomic to work with.

[WillXuCodes]

This is a good idea, I'll bring it up with the team soon. Another thing we could do more is utilize stderr if teams are connected through the terminal as another indicator that something went wrong other than through the return error.

[nickmertin]

Printing to stderr is fine, but there definitely needs to be a programmatic way of determining the error as well.

[WillXuCodes]

yeah I'm aware, I brought that up as an addition rather than an alternative.

[WillXuCodes]

Forgot to mention, but we've come to the conclusion that despite being a more elegant way of handling errors, it would most likely be less intuitive for the average high school student. The current system while not perfect, is still most likely the easiest way of indicating that something went wrong. Libraries on top of PROS (like Okapi) are more suited for building a system like this for more advanced users.

[WillXuCodes]

Also, I'm going to be honest, I don't think we'll be able to knock out VFS implementation for PROS 4 release. I think that's going to have to be a post-release type deal.

[nickmertin]

Fair enough, as long as we make sure the API on release is forwards-compatible.

[WillXuCodes]

https://drive.google.com/file/d/1XcrE97G7Fm6GN-kjT6ok3h1rQyg6L0HO/view?usp=sharing

Document for our official plans (more professional than the MS paint picture).