The only problem with your naming system is that colons are already taken as syntactic sugar for function composition. If you're interested in package systems for arc, you could look into what almkglor did on Anarki. It was a pretty thorough overhaul of most of arc, but I don't think it's supported anymore.
Strictly speaking, it doesn't need to be so thorough.
It's possible to make the contexting system be less aggressive about putting symbols in packages.
As an explanation, contexting performs the following transform:
; Arc-F code!
(in-package foo)
(using <arc>v3)
(interface v1 public)
(def private (x)
x)
(def public (y)
(private y))
; equivalent transform!
t
t
t
(<arc>def <foo>private (<foo>x)
<foo>x)
(<arc>def <foo>public (<foo>y)
(<foo>private <foo>y))
Because of its aggression, everything gets to be a pretty thoroughly pushed to some package.
However, you can reduce the aggression instead, at the cost of declaring private functions:
; Anarki-on-arc3 code!
(in-package foo)
(using <arc>v3)
(internal private)
(interface v1 public)
(def private (x)
x)
(def public (y)
(private y))
; equivalent code!
t
t
t
t
(def <foo>private (x)
x)
(def <foo>public (y)
(<foo>private x))
In short, instead of assigning unpackaged symbols to the current package, it leaves unpackaged symbols. This retains as much back-portability with ArcN as feasible.
However you still need to force contexting in your REPL/load, i.e. RCEPL, read-contextify-eval-print loop.
I won't be working on Arc-F, since I have my own project now, and stefano is squeezing me to get a REPL on it some time soon ^^
