we currently have 3 different ways of providing functions:
(the same is true for types, so will ignore that for now, as it will have the same solution)
darklang.comdarklang.comWe have plans to unambiguously name functions and provide a list is at the top of files for readability:
alias add = stdlib/Int.add_v0
alias addOther = user/Int.add_v0
1 |> add 2 |> addOther 7
Int.add_v0
even though we also have Int.add_v0
Int.x
and the user previously had a fn Int.x
List.take
does not need to be written in F#, so perhaps should not be in the stdlibList.take
is actually stdlib/dark/List.take
and it is finds whichever one is available in the set of stdlib functionsList.take
as a package to remove code from the core runtimeList.take
to be redone for performance we could add it to F#“I've been thinking that we own dark.Xpackage.X
is 'taken' whenever a user publishes a package (first one wins)
anything local is basically [username/org].X
regarding functions like List.take that can be written in Dark, and "how do we manage the breakdown of F#-defined and Dark-defined stdlib functions": I can't think of a good reason to separate "packages" from stdlib - the idea of "stdlib" is just a set of packages that we avail official in dark. submodules
for example dark.Int.add
, dark.HttpHandlers.Request
”
dark/Int.add
dark.int.add (casual?
within that is there an int module?
what about helpers? just add _fnName
where does ‘=’ live? dark.builtin.=?