Open harrysarson opened 5 years ago
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.)
All functions used by *.elm
files and all functions that can be called by compiler generated js :+1:
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
is called in elm
https://github.com/elm/core/blob/665624859a7a432107059411737e16d1d5cb6373/src/Basics.elm#L533-L535
and so we deduce that
a
andb
must have typeInt
and the function returns anInt
*.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
It is far from clear. Looking at the use of
stepperBuilder
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.
String
,List
etc to this function. There is no checking that the javascript function actually returns anInt
. This is why folk see96 \= 0
having a type ofBool
and a value of0
(https://github.com/elm/core/issues/1022).