V: restructure standard library

[superwhiskers]

summary

• remove non-essential, more platform-integrated modules from the standard library, like the ui framework, so they aren't holding back full support for other platforms and place them into an "extended" library
• make modules that will work on all platforms as soon as basic code generation for a platform works go into a "core" library

structure

• core library: modules that work across all platforms without needing portwork (stuff like the optional type and other things that only rely on working machine code generation)
• standard library: modules that are essential for more complicated libraries/programs like filesystem access and the like. requires some portwork to actually function
• extended library: modules that are more platform integrated and aren't exactly necessary for a program such as a ui framework and other things.

the standard library should be relatively minimal as to not hold up porting the language to other platforms. it shouldn't contain unnecessary things, it should be as small as possible without compromising the functionality of the language itself.

rationale

it would make the core language much easier to port and would make it more attractive for a wider audience than if it were to have a more heavyweight standard library. it also keeps the ui library's platform support from being inconsistent from the rest of the standard library, and allows people to begin using the language at a minimal support level as soon as machine code generation works for a platform easier, as we could release it without standard library support for said platform being unfinished

footnote

suggestions of improvement are welcome.

[kinggoesgaming]

we can have std that contains the basic stuff that everyone may need as a necessity and have a stdx as an extended std with extra stuff as batteries included

[superwhiskers]

but what about core

[kinggoesgaming]

but what about core

I actually don't like the core/std system in Rust. Instead a config attribute based system might be better.

[superwhiskers]

I actually don't like the core/std system in Rust. Instead a config attribute based system might be better.

i think it would allow for easier tracking of v's support on a platform, and it makes it easier to use v on a platform instead of requiring you to say that you're using x libraries from the std. it compartmentalizes the standard library as a whole instead of requiring you to pick and choose which parts you want to rely on. sure, you could check which parts something is relying on by checking imports, but i personally think it would be much simpler to separate out the std into three chunks, each with varying levels of platform-independence

[Chamberlain91]

I like this idea!

It would seem to make the core part very tight for purely computation things, while something with a little more oomph like a program to count files in a directory needing standard or a ui based calculator needing extended.

Makes sense to me really, lends itself to smaller platforms, like lets say a raspberry pi. You might be entirely headless and not need ui module ever. I'm sure there are some platforms that run C executables that never have a display and thus never need something like ui.

[superwhiskers]

that was basically the rationale, that not every program will need the ui module so why would it ever be in the std

[ghost]

...while something with a little more oomph like a program to count files in a directory needing standard...

This idea made me think about the structure of ArchLinux's pacman repositories.

@Chamberlain91 I think it's more convenient to put the File feature in core as it's frequently used.

[superwhiskers]

core isn't for frequently used things @lhy0403, it's for platform-agnostic code that doesn't require additional portwork outside of basic code generation for a platform. File would require syscall support, which is system-dependent, therefore it would belong in the standard library

[Chamberlain91]

I don't fully comprehend the difference between standard and core myself, I just assume core would've been CPU level features and standard was OS lower level features (files, network, etc), and extended was OS higher level features (ui, notifications, etc)

[superwhiskers]

core and std are akin to rust's core and std, while extended is for stuff like the ui library and other modules heavily dependent on platform-specific things as they would take longer to port

[Chamberlain91]

I'm not aware of how rust (or really even go works 😅) but my friend pointed out this language repository and I've taken a liking to the design.

[ghost]

So what features or packages could be located in platform-independent core library?
e.g. JSON, Image-format libraries, Encryption libs (this could rely on Windows CSP or openssl so not really in core), and what else?

[superwhiskers]

the option type

[superwhiskers]

and some basic enumerations

[superwhiskers]

integer type stuff

[superwhiskers]

the primitive integer type should just be an integer type, then have the core lib shadow it so it has methods

[superwhiskers]

right now the built-in integer has stuff that could just be handed off to a core library instead of unnecessarily bloating builtins

[superwhiskers]

same with any primitive type. you shouldn't bloat primitives. they're meant to be primitive

[superwhiskers]

that does lead into the question of if lists should be primitive or added in the core lib. same with maps

[superwhiskers]

and about just how "systems" this programming language should be

[ghost]

So you mean methods of strings, conversions, arrays, maps, and enums, classes (do we have classes or structs?) are in core lib right?

ADDED: Github emails really messed up my inbox 😂...

[superwhiskers]

no, core would theoretically contain all of the shadowed primitives which adds conversions to other types, helper methods, etc

[medvednikov]

gg, glfw, gl, glm, ui will not be part of vlib (stdlib).

[watzon]

I agree with this. Basically what is needed is a prelude library (the library that includes all of the basic functionality v needs to work) and a standard library (which would include all of the functional extras; http, json, crypto, etc). Other modules like glfw, glm, ui, etc. should ideally be separated into official modules that will be installable with the package manager once it's released.

If you look at the language Crystal, which has been around for some years now, they are dealing with this a bit late in the game and it's proving to be an issue because so many things depend on other things. Getting ahead of this and coming out with an official roadmap could be a good idea.

[medvednikov]

Again, all these extra modules will be split up. I already created repos:

https://github.com/vlang/gg
https://github.com/vlang/ui
...

The standard library will be small like Go's and with zero dependencies (except for OpenSSL on Linux and macOS).