Question about process

[jmagaram]

I'd like to understand the process of ensuring the result here of this "you don't need to reach for anything else for typical ReScript development." Maybe there is a well defined process and I just don't know what it is, so forgive me.

I started using Core in the past week and I've noticed a few big holes. First, I couldn't create an array of 10 items consisting of the numbers 1...10. Previously I'd use Belt.makeBy. On GitHub I can see these features from Belt were added very recently but aren't in the version I'm using. There are times I get an error result from an external API and I want to convert it to my own version. F# has a Result.mapError which seems pretty useful. There are times you want to take two options and concat them; in F# this is the map2 function or could be a let concat: (option<'a>, option<'b>, ('a, 'b) => 'c) => option<'c>. And so I'm curious whether there could be improvements to the design process to ensure we end up with a cohesive package .

I think a good process for array or any built-in type would be something like this. Look at ALL the functions from similar languages/projects - built-in JS functions, F#, PureScript, fp-ts, OCaml, Haskell, Belt, ramda/lodash. Put them all in a spreadsheet. See where they overlap in function but not necessarily name - maybe a column for each project and a row for each function. Group them into constructors, mappers - like from one array to another array, utilities - those that exit the type like array.length. Mark the ones that seem fundamental and should be included and the ones that are too niche for inclusion. Mark the immutable vs. mutable. Make a proposal for a final set with consistent naming. Publish this spreadsheet somewhere so we can all see it. Get some feedback from community.

[zth]

Sorry I missed this, and this will have to be a quick reply, but wanted to clarify a few things:

• "you don't need to reach for anything else for typical ReScript development." primarily refers to people used to JS development. I get the feeling you're more "functionally" oriented, and it's not in the scope of Core to be a fully fledged functional library. That's not to say that working in a functional style isn't great or something you should do, it's just that we need to draw the line somewhere for what Core is, and we've decided that staying close to regular JS is most important for something included in the "base package" of ReScript. Fully functional libraries are welcome too as their separate thing maintained in user land. It's just out of scope for Core.
• Core isn't designed to be a fully green field library. Core is very specifically designed to solve one of the larger problems in ReScript right now (confusion around all of the available APIs, data first/data last, OCaml standard library). We need to be attentive to the fact that this is supposed to one day replace what's already in ReScript (the JS namespace primarily). So this needs to have a solid migration path, ie stay fairly close to the regular JS namespace and how JS works.
• We might add things to Core in the future (we've already covered a few holes and added a few things we feel fit), but that's not the main phase we're in now. Right now, what's important is getting Core to a state where it's a really solid alternative compared to what we have today, with a great DX, documentation and so on. Later we might be more interested in expanding it, when Core is polished, there's a worked through strategy for how to bring this into the compiler, it works with the upcoming uncurried by default, etc.

So, reading what you've written in multiple places, my impression is that you're looking for Core to be something (more functional, cover more ground) that it's not intended to be. But, we do appreciate you wanting to help with Core! What we need to the most help with right now is docstrings and documentation. Check out this issue and grab a few modules to do docstrings for, that'd be most appreciated: #25

[jmagaram]

I agree the confusion about data first/last, String and String2, is a big problem worth solving and I'm glad you're doing it. It makes sense to initially focus on bindings for base Javascript. Option and Result have no analogous types/libraries in JS. If you're going to include them, I think they should be reasonably complete. I wonder if eventually it would help to fill out the Array module with functions people see in the core libraries of Rust and F# and others. Functions like zip, pairwise, distinctBy, etc. These are just so convenient and Array is the most used/necessary data structure in JS. For DX it is good to know you'll probably find what you need in Core.Array without also having to reach for Ramda.Array or something else.