Add the package std module

[jneem]

Depends on #2110

Adds a package module to std, with contracts related to package manifests.

As I was making this PR, it occurred to me that maybe some of the contracts (e.g. the semver ones) could be parsing into a structured representation instead of just validating. What do you think?

[github-actions]

Bencher Report

Branch	std-package
Testbed	ubuntu-latest

Click to view all benchmark results

Benchmark	Latency	nanoseconds (ns)
fibonacci 10	📈 view plot 🚷 view threshold	497.26
foldl arrays 50	📈 view plot 🚷 view threshold	1,709.50
foldl arrays 500	📈 view plot 🚷 view threshold	6,786.60
foldr strings 50	📈 view plot 🚷 view threshold	7,075.50
foldr strings 500	📈 view plot 🚷 view threshold	61,843.00
generate normal 250	📈 view plot 🚷 view threshold	40,853.00
generate normal 50	📈 view plot 🚷 view threshold	1,987.30
generate normal unchecked 1000	📈 view plot 🚷 view threshold	3,353.40
generate normal unchecked 200	📈 view plot 🚷 view threshold	771.75
pidigits 100	📈 view plot 🚷 view threshold	3,190.40
pipe normal 20	📈 view plot 🚷 view threshold	1,509.10
pipe normal 200	📈 view plot 🚷 view threshold	10,045.00
product 30	📈 view plot 🚷 view threshold	848.62
scalar 10	📈 view plot 🚷 view threshold	1,549.90
sum 30	📈 view plot 🚷 view threshold	830.55

🐰 View full continuous benchmarking report in Bencher

[yannham]

Looks reasonable so far.

With respect to semantic versioning, we could indeed parse it on the way (since we're running the regex anyway), I guess that will spare re-parsing it on the Rust side. It would also allow people (if we write the right contract) to use either a structured representation or a textual representation as an input. The final representation would be always structured (in fact even that is not required, we could keep a union, but I don't think it has much of an advantage).

Regarding optionals, I don't have a strong opinion myself but I guess we could look at the manifest format of some prominent languages that seem to have done things right and try to extract a common base of attributes that are required everywhere.

[yannham]

Nitpick: we indent the documentation in the rest of the stdlib.

Suggested change

	| doc m%"
	The name of this package.
	"%,
	| doc m%"
	The name of this package.
	"%,

[yannham]

Should this be enum tags instead? But it's less nice to express as a static type (we can use a contract like std.enum.EnumTag or I don't remember how it's called, but for a static type we would need proper existential like exists a. [| ; a |])

[jneem]

Mostly I picked String because the set of reasonable values is open and possibly large.

[yannham]

I was going to say that we should put each payload into its own type, but then that won't be usable in statically typed anymore as we don't have let types yet. Is that why you inlined all the structure here?

[jneem]

Honestly, it was just because the first version had less fields, and then I didn't split it out as the number of fields grew. I'm not sure that static typing is a big concern here, as we don't have functions that consume and produce Manifests. (At least, not yet. But by the time we do, maybe we'll also have let type...)

[yannham]

Well, if we put it in the stdib, people might want to do that, so we could be tempted to leave it as it is and then later split it in a nicer way once we have let types, without disturbing user code.

On the other hand if we split it into contracts now this reduces what users can do with manifests but we can still introduce let-types later and that would be a backward-compatible improvement, which has been our strategy for many things up to now. So indeed if the stdlib doesn't really need the statically typed side, I guess we can go both ways.

[dpulls]

🎉 All dependencies have been resolved !