namespaces and a require/loadpath mechanism

[alandipert]

To follow a subset of Clojure's namespace operations.

Namespace data

• Namespaces are symbols that:
  • Don't contain a /
  • Can be munged into a filename, see require below.
• A "namespaced symbol" is a symbol like x/y
  • x is the namespace component
  • y is the name component
• Namespaces represent:
  • A collection of global definitions
  • In a file on the filesystem named symmetrically with respect to munging rules, see require below

Namespace operations

• An (in-ns ns) form that set!s gherkin.core/*ns* to the symbol ns and refers primitives a la refer-clojure. *ns* should default to user.
  • Don't need an ns form or to the ability to not refer core primitives automatically into new namespaces (yet).
  • An ns-alike can be a macro baked into the interpreter.
• (def x val) installs val at *ns*/x
• gherkin.core/*load-path*, a list of strings representing the list of paths to treat as the top of the namespace search path. Should default to ("."). Command-line support for appending to the load-path like java's -cp.
• (require 'foo) that searches the load-path for a foo.gk and evaluates it, returning to the caller's *ns* following evaluation. Definitions in foo may be referred to with foo/some-def.
  • Namespace symbols should be munged by require such that (require 'foo.bar.baz-ns) results in a search for the file foo/bar/baz_ns.gk on the load path.
• (require '(foo as f)) installs an "alias" of f for the namespace foo in the current *ns* such that definitions in foo may be referred to by either foo/some-def or f/some-def

Implies

• A binding primitive

Open questions

• Should analyze() or the nascent syntax-quote attempt to resolve globals?
  • Probably not - analyze() is already not the fastest, and by its current nature we'd incur resolution overhead on every fn invocation
    • Maybe analyze could only resolve globals once, and then replace the fn source with code in which all symbols were either lexically resolved or namespaced?
• What about use and refer?
  • I don't think we need them, and they complicate implementation by necessitating a new per-ns array in which to store them.
  • Similar functionality could be achieved with a macro that "mirrors" remote definitions.
• Should we support exporting a namespace as a .sh file containing a partial heap?
  • .sh would contain a set of array declarations. The arrays would need to be specially named so that after the .sh is sourced we can work with the arrays. These arrays would consist of at least:
    • cons heap
    • map of namespaced symbols in the ns to either
      • a cons in the heap
      • a literal
    • interned_symbols
  • Libraries could ship as partial heaps and they wouldn't need to be read in order to be used
  • Need semantics for merging partial heaps
    • Merge remote heap and remote interns with global heap and global interns, updating the remote globals and merging them into the world when done.
    • Implies a deep copy of remote conses into the requirer's heap