-
Notifications
You must be signed in to change notification settings - Fork 30
Description
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.
Activity
zth commentedon Mar 13, 2023
Sorry I missed this, and this will have to be a quick reply, but wanted to clarify a few things:
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.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 commentedon Mar 13, 2023
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 forRamda.Array
or something else.