Namespacing - HackMD

# Design: Namespacing **Author**: @sdouglas ## Description (what) Currently all declarations are of the form `<module_name>.<decl_name>`. Namespacing will expand on this to add both namepsaces within modules and the ability to directly reference declarations in another realm. ## Motivation (why, optional)  ## Goals - Introduce a naming scheme that supports both namespaces and realms - Map this naming scheme all all existing supported languages ### Non-Goals (optional) - Realm support other than naming and schema representation. ## Design (how) A FTL name can be represented as follows: ``` name ::= [ realm "/" ] module ("." namespace)* "." declaration ; realm ::= identifier ; module ::= identifier ; namespace ::= identifier ; declaration ::= identifier ; identifier ::= letter (letter | digit | "_")* ; letter ::= "a" | "b" | "c" | ... | "z" | "A" | "B" | "C" | ... | "Z" ; digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ; ``` If the realm is omitted then it is assumed to be the current realm. This is defined to be the same realm that a module is deployed to when inside the cluster, and the realm that the `ftl` CLI tool is configured to work with when outside the cluster (TODO: does this make sense?). WIP: A few options are possible for how this is represented in the schema: ## Option 1 Create a new `Namespace` decl, that can contain other decls. This means both modules and namespaces can contain declarations, so to enumerate all declarations you would need to recursivly check all namespace decls as well as the module itself. Pro: The underlying data stucture exactly matches what the end user is seeing Con: Code dealing with the schema and resolving types may be slightly more complex Con: Decls can be in multiple places (module and namespace) ## Option 2 As per option 1, except that decls can only be in namespaces, with some concept of a default namespace added to allow for `module.Decl` syntax. Pro: Everything is in a namespace, only one type of decl container Con: Default namespaces may be confusing ## Option 3 Create a new `Namespace` decl, but leave all decls under the module. A decl `Bar` under the namespace `foo` would just have a name of `foo.Bar`. Pro: All decls are still represented at the module level, no need to scan multiple namespaces Con: Allows for inconsistent schema (`foo.Bar` with no namespace `foo`, hower that could be handled by validation, or through implicit namespace creation) ### Required changes (how)  ## Rejected Alternatives (optional)