Yeah, I frequently see people hacking together their own namespace systems, and either trying to go for the most complete and cumbersome system possible (handling dependencies, versions, etc.) or something that isn't general enough to be used more than once.
Maybe we should try and design a set of very basic namespace handling tools, and then allow users to extend off of them. Basic as in "See namespace. See namespace hold names. See namespace export names for use" If we make them simple enough, and generic enough, it should be possible to add whatever other features are necessary later.
Right now the only hard part about implementing namespaces seems to me to be support for macros. Anyone have any ideas on how to allow macro indirection via namespaces without having first class macros? Or maybe just a good way to handle first class macros themselves?
Anyone have any ideas on how to allow macro indirection via namespaces without having first class macros?
Lathe's approach (where namespaces are friendly-name-to-unfriendly-global-name tables encapsulated by macros):
arc> (use-rels-as ut (+ lathe-dir* "utils.arc"))
#(tagged mac #<procedure: nspace-indirect>)
arc> (macex1 '(ut (xloop a list.7 b 0 a.b)))
(gs2012-xloop a list.7 b 0 a.b)
arc> (macex '(ut (xloop a list.7 b 0 a.b)))
((rfn next (a b) a.b) list.7 0)
arc> (ut:xloop a list.7 b 0 a.b)
7
Maybe we should try and design a set of very basic namespace handling tools, and then allow users to extend off of them.
Funny, that's part of what I had in mind as I made Lathe's module system. :-p Is there some aspect of Lathe's namespace handling that's inconsistent with what you have in mind? The point of the Lathe module system is mainly to keep the rest of the Lathe utilities safe from name conflicts, so I'll gladly swap it out if we can come up with a better approach.
