Advice on standard library to use

#21

So there are two answers to that, one is “in the future, as designed” and one is “right now, in alpha version”.

  1. a. In the future: There should be almost no overhead - they’re almost all simple wrapper functions, and the compiler should be able to optimize them all to nothing (I dont know if that is in fact the case though). We deliberately wrap the platform-native types, as those library writers have spent time on this.
    b. Now: Most of the code is really quickly written, hacked together, and will not do well in a benchmark. If you look at the code, you’ll see we often convert something to a list and back to an array to use whatever functions Belt had available. However, while they could certainly be improved, we haven’t seen any slowdown in our app. We will certainly be improving them, and welcome contributions to help with this.
  2. The goal of Tablecloth is to not have to think about the differences between Belt, Core, Base, and other libs you app may use like containers, batteries, etc). If we need new high-level functionality and it isn’t in Belt, we should add it to tablecloth. If some functions we’re building already exist in Belt, use them. I haven’t got a sense of what it’s like to contribute to Belt, as my goals were different than Belt’s.
  3. I haven’t seen this happen in practice, and I don’t have a plan here.
  4. Por que no los dos?
#22

I missed this conversation the first time around.

I am a bit confused about t-first/t-last argument since Base also adopts t-first convention

I have started casually referring to JaneStreet’s convention as “t-middle” (that term is not endorsed by anyone I just needed a way to refer to it). It seems they are pretty consistent with putting the positional arguments in the middle, with the optional named arguments on the left, and the non-optional named arguments on the right.

In addition to that convention, Base/Core seem to make very heavy use of labeled arguments and typically only one positional argument - though it’s not always the case. In the event that a function takes two positional arguments I believe the “main” positional argument would come first. (Can you find a counter example?) It’s rare that you have two non-named arguments though.

This convention has some nice properties, such as removing the problem with optional named arguments, and typically avoids ever having to include a unit argument to “fill in the defaults” for the optional arguments.

#23

Thanks, I hadn’t heard of this before and its exactly what I was looking for.

After getting to grip’s with Base/Core I really, really like its consistency and the way it uses labelled arguments. Its definitely something I would love to see more of in reason-land.