Add stdlib docs

[tom-sherman]

These docs are missing on the site, would you accept a PR adding them?

https://reasonml.github.io/api/index

[ryyppy]

Hey,

Thanks for the report.

Let me give you a quick overview of what modules docs we would accept:

• Pervasives ... but some functionality in there is actually not recommended for usage, e.g. string_of_int (vs. Belt.Int.toString), etc.

Following modules will not be accepted for following reasons:

• Array ... use Js.Array / Belt.Array instead
• List, ListLabels ... use Belt.List instead
• String or even Str ... use Js.String instead
• Set ... use Belt.Set (+ its variants) instead
• No Bytes, Buffer, Callback, Digest, Complex, Filename, NativeInt, Stream, Random, Scanf, Sys, Unix. Those are platform dependent and probably won't compile (or at least not nicely) on JS and are too native oriented
• Stack ... use Belt.MutableStack instead
• Sort ... use Belt.SortArray instead (besides, Sort is even deprecated in OCaml)
• No Docstrings, GenLex, Lexer, Lexing, Location, Longident, Parse, Parser, Parsetree, Pprintast, Printast. These are literally compiler building modules, we don't expose that to our users.
• No Oo.. ReScript doesn't expose object related syntax features
• No Obj... this one is a little weird, since it shouldn't be used by any users, not even Obj.magic
• No Gc... doesn't look like something we want to expose to JS users
• Hashtbl ... use Belt.HashMap (+ variants) instead
• No CamlinternalFormat, CamlinternalLazy, CamlinternalMod, CamlinternalOO, ... those are internal and probably not useful for our JS users

For OCamlers who still need to use the OCaml related libraries, it's probably better to refer to the actual OCaml 4.06 docs instead. We care mostly about the JS target here, so we recommend our JS optimised modules (which are also partly adapted OCaml stdlib modules). It's most likely also easier to read for them since they are using OCaml syntax.

Following modules I am not sure, but for now it's not accepted:

• Queue .. no idea on how useful this is for JS compilation and if it's optimized for JS usage
• Bigarray, Int32 / Int64 .. not sure about those.. we should probably offer a Belt.BigInt at some point
• Num ... not sure if this translates to JS
• Syntaxerr... not sure if useful for JS context
• Weak... not sure if it translates to JS
• Printexn .. not sure about this one, probably not equivalent to Js.Exn
• Arg ... not sure if useful for JS (we have better alternatives in the JS ecosystem)

Hope this makes sense.
Would be happy to review a PR adding Pervasives, or the Node module (located in the rescript compiler).

[yawaramin]

Thank you for the explanations. AFAIK Num is dependent on C bindings so it wouldn't translate anyway (and anyway for big numbers Zarith is recommended and there is a bs-zarith port).

It would make sense to put the above explanations in a documentation page(s) in the API docs section, so that it was more discoverable.

[ryyppy]

It would make sense to put the above explanations in a documentation page(s) in the API docs section, so that it was more discoverable.

Probably good to have on the API overview page, right when you enter the API docs for now?

[fhammerschmidt]

This is superseded by Core which is automatically generated. Everything that is not in Core (or Belt or Js) won't be documented anymore anyways.