Private global definitions

[HuseyinSimsek7904]

Consider this piece of code from the standard library.

//// From ./std/collections/list64.corth

//// This macro should NOT be available publicly.
// ptr: list64 -> ptr: dynamic
macro get-dynamic @64 endmacro

//// This macro should NOT be available publicly.
// ptr: dynamic ptr: list64 ->
macro set-dynamic !64 endmacro

//// This macro should NOT be available publicly.
// ptr: list64 -> ptr: array
macro array-addr list64:get-dynamic 8 + endmacro

//// This macro should NOT be available publicly.
// ptr: list64 -> ptr: array int: length
macro to-array let _list_ in
  _list_ list64:array-addr _list_ list64:length
end endmacro

//// This macro should be available publicly.
// ptr: list64 -> ptr: array
macro copy-array list64:to-array to-dynamic64 endmacro

In this piece of code, there are macros that should only be accessible inside list64.corth. In Corth, there should be a way to tell the compiler which parts have access to specific parts of code. This would improve the compilation times as well since the compiler needs to check fewer definitions while trying to compile procedures.

[HuseyinSimsek7904]

One way to implement something like this may be private definitions.

// Names are defined under the _list64 namespace. Other namespaces can not access these names without 'using' them.
private namespace _list64
  // ptr: list64 -> ptr: dynamic
  macro get-dynamic @64 endmacro

  // ptr: dynamic ptr: list64 ->
  macro set-dynamic !64 endmacro

  // ptr: list64 -> ptr: array
  macro array-addr list64:get-dynamic 8 + endmacro

  // ptr: list64 -> ptr: array int: length
  macro to-array let _list_ in
    _list_ list64:array-addr _list_ list64:length
  end endmacro
endnamespace

// Namespace list64 uses the namespace _list64, this means any procedure inside list64 can access names defined under _list64.
using _list64
namespace list64
  // ptr: list64 -> ptr: array
  macro copy-array list64:to-array to-dynamic64 endmacro  
endnamespace

This approach would work well for procedures, however macros will not work as expected. This is because macros directly copy their tokens, which means that they can not have access to names that the expander procedure does not have access to.