Goal:

• determine how we should resolve and prioritize function names

Context:

• we currently have 3 different ways of providing functions:

  • user functions, created by the user
    • myFunction_v2
  • package functions, provided by the package manager
    • eg dark/stdlib/AWS.urlEncode_v0
  • Standard lip functions, written in F# and packaged into the executable

• (the same is true for types, so will ignore that for now, as it will have the same solution)

• We 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
  

Problem/solution:

• we don't know how to unambiguously refer to functions, and what the edge cases are.
  • in the example above, are users allowed create functions with the same name, just in the user namespace?
    • if not, we are limited in functions we can add
    • ergo, yes they are
    • this tells us that users are allowed add the function Int.add_v0 even though we also have Int.add_v0
  • we need a rule for how we recognize this in the parser - it needs to be unambiguous, and new functions shouldn’t beat old ones
    • what if we add a function Int.x and the user previously had a fn Int.x
      • starting to look like having IDs (or content-addressible data) might be needed here
• we’d like to move some functions between the package manager and stdlib
  • for example, List.take does not need to be written in F#, so perhaps should not be in the stdlib
  • but, we’d still like a big “batteries” included set of functionality
  • Also, we'd like to occasionally replace standard library functions with ones written in F# for performance
  • As such, it makes sense that the standard library and a prefixed area of the package manager should share space
    • eg List.take is actually stdlib/dark/List.take and it is finds whichever one is available in the set of stdlib functions
    • we could add List.take as a package to remove code from the core runtime
    • if we need List.take to be redone for performance we could add it to F#
    • if we have a new performance improvement when running dark code, we could remove it from F# again

“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.=?