Elaboration on motivation?

[littledan]

I took a look at this specification, and it's hard for me to see why these are needed in JS itself as opposed to user-level libraries. Are any of them more efficient to implement on real hardware? Which ones? What makes user-level libraries inadequate for things like converting between degrees and radians?

[rwaldron]

and it's hard for me to see why these are needed in JS itself as opposed to user-level libraries.

From the readme:

Providing them as built-ins paves a widening cow path. Implementations of all can be found throughout many modules on npm, of varying quality and consistency.

Additionally, your statement could be made for many things that we've standardized in the language.

Are any of them more efficient to implement on real hardware?

I said: "JS-on-hardware, JS remotely controlling hardware & IoT project", but it's actually not really relevant to be that specific—don't get too hung up on it. It's "JS doing Math". My mention had nothing to do with efficiency of implementation on "real hardware" or not, but more to do with "these operations are extremely common in this environment for these types of applications".

What makes user-level libraries inadequate for things like converting between degrees and radians?

Why should such operations require the inclusion of user libraries when they are built-ins in other languages?

• Java
  • https://docs.oracle.com/javase/7/docs/api/java/lang/Math.html
• Python
  • https://docs.python.org/2/library/math.html#angular-conversion
  • https://docs.python.org/3/library/math.html#angular-conversion
• Racket
  • https://docs.racket-lang.org/reference/generic-numbers.html#%28def._%28%28lib._racket%2Fmath..rkt%29._degrees-~3eradians%29%29
• Rust
  • https://doc.rust-lang.org/std/primitive.f32.html
  • https://doc.rust-lang.org/std/primitive.f64.html

Why should they not be available as built-ins in JS?

[littledan]

I read your readme. When you say "paves a widening cowpath", do you mean you think it would make sense to standardize more Math methods? Any particular idea which would be a good idea to add?

I think few of the library additions we've made recently are as simple as these. Maybe some like Number.isNaN, but that is nice because it subsumes an earlier library function. One reason why we might want to add something is if it's useful for a broad amount of code, that it would be more efficiently implemented in the VM core, or that it is sufficiently nontrivial and easy to get wrong that we want to take the task away from fallable VM authors.

Each of these math functions you are adding seems to have a very simple definition, and I have a hard time understanding what's cleaner about using the additional library.

• map and fmap: I don't see it documented besides a definition, but looks like you're linearly mapping something from one range to another, right? I don't really understand what's clearer about abstracting this into a function than just having the code inline. I can understand that this comes up a fair bit, but the name is a little confusing, as it doesn't really related to either Maps or Array.prototype.map.
• constrain: To me, the nested min/max calls looks just as clean; less concepts to understand. When I see the word "constrain" it makes me think more like map's semantics.
• degree/radian conversions: What if you just add the single constant, DEG_TO_RAD, which users can multiply and divide by? Not sure what additional value you get from adding four things over that. I think JS already got it right by using the more natural unit, radians, for its trig functions (though, come to think of it, the spec never says that...).

I think it's a good idea to look at what we should be adding to the JavaScript standard library, but I'd also like to weigh the benefit of making these additions against the cost in terms of, e.g.,

• Implementing several times, at least once in each ES implementation, as opposed to once in the library
• Increasing the size of things by making more functions (yes, I know I argued the opposite in the SIMD.js case; this might not be that important, but it actually remains nonzero cost in many implementations at the moment)
• Carrying around the same frozen interface forever, when we might get things wrong the first time (no particular concern here, but it happens)
• Web compat risk from "polyfill" libraries which add same-named things to Math

Those aren't arguments against this particular proposal, just that all library additions should have some reasonably strong positive justification, rather than turning it around as "why should they not be added".

But don't get me wrong, I really want to see the ES standard library improve over time, and for example, I'm happy about the additions that we got in ES2015. I'm just not sure whether these are what we should be adding next.

[rwaldron]

I can understand that this comes up a fair bit, but the name is a little confusing, as it doesn't really related to either Maps or Array.prototype.map.

This name is one of three possible names that I present.

The rest of your comments seem better suited to meeting time discussion.

[littledan]

Happy to discuss it in the meeting; I just wanted to give you feedback ahead of time so you can prepare. See you tomorrow.