Document the "elm type" of kernel functions

[harrysarson]

Kernel functions are defined in JavaScript (no static typing) but can be called from elm (static typing) and thus have some sort of implicit type signature.

For example the kernel function

https://github.com/elm/core/blob/665624859a7a432107059411737e16d1d5cb6373/src/Elm/Kernel/Basics.js#L17

var _Basics_remainderBy = F2(function(b, a) { return a % b; });

is called in elm

https://github.com/elm/core/blob/665624859a7a432107059411737e16d1d5cb6373/src/Basics.elm#L533-L535

remainderBy : Int -> Int -> Int
remainderBy =
  Elm.Kernel.Basics.remainderBy

and so we deduce that a and b must have type Int and the function returns an Int*.

---

However, other functions have much stranger signatures. For example, what is the type signature for stepperBuilder here?

https://github.com/elm/core/blob/665624859a7a432107059411737e16d1d5cb6373/src/Elm/Kernel/Platform.js#L35

function _Platform_initialize(flagDecoder, args, init, update, subscriptions, stepperBuilder)

It is far from clear. Looking at the use of stepperBuilder

var stepper = stepperBuilder(sendToApp, model);

stepperBuilder is function that takes two arguments (which is not allowed in elm) but what are the types of those arguments? What is the return type?

If elm-in-elm is able to implement kernel code for targets other than javascript, or move logic from "kernel space" into "elm space" then we first need to solidly document all these implicit type signatures.

---

I am proposing an effort to compliment the documentation written as part of #57 with type signatures.

---

• There is no checking (neither compile time or run time) that an elm function does not pass a String, List etc to this function. There is no checking that the javascript function actually returns an Int. This is why folk see 96 \= 0 having a type of Bool and a value of 0 (https://github.com/elm/core/issues/1022).

[Janiczek]

I agree it would be helpful to end up with a concise list of functions other targets have to implement, and their types. :+1:

Just want to check - we don't need to document all JS functions, just the ones exposed by immediate usage from *.elm files, right? (Transitive dependencies are implementation detail and the other targets might choose to not take the same approach to implement the immediate dependencies.)

[harrysarson]

All functions used by *.elm files and all functions that can be called by compiler generated js :+1: