[stdlib] Splitting prelude

[mbouaziz]

I'm again encountering the issue of something compiling fine locally but failing on the CI because it is using a different stdlib.

IIRC, the plan was to split the prelude into:

• intrinsics: declaration of functions that the compiler knows, sk files + the llvm preamble (must be distributed with the toolchain and we must use that version rather than the local one)
• runtime: what compiled programs will be linked with to run, .a file (same)
  • both will be added to the bootstrap and can be combined as an sklib file
• stdlib: just a bunch of sk files

Anything against this plan?

[jberdine]

I think that there are also a few corners that we will need to be careful of. For example the type definition in skiplang/prelude/src/native/StringIterator.sk needs to be kept in sync with skiplang/prelude/runtime/string.c since some C functions access the representation directly. So the division between "intrinsics" and "stdlib" might be not very clear-cut.

[mbouaziz]

Indeed, there are a few classes to handle specifically:

1. native value classes: Void, Bool, Char, Float, Int, Int8, Int16, Int32, RawStorage, GCPointer, NonGCPointer
2. native classes: Array, String

• though is there a difference between value and non-value native classes given they have no front-end fields?

3. native base classes: Obstack, Page

• though why are they base classes given they have no children?

4. native class SpawnFileActions: malloc'ed structure, should probably be done differently
5. classes that are not native but there's a link between their representation and the runtime: StringIterator, Mutex, Condition

1 and 2 should be declared in the intrinsics and have extensions in the stdlib.
3, 4, 5 can be in the stdlib, though they somewhat depend on the compiler version (but Skip code too!). It can contain C code as well.