Something else that would be hard to develop, but possibly pretty innovative, is if an arc package system were tied to a git-like patching system:
This means that a package could "modify" instead of just "adding" to the code.
In most languages, this wouldn't be a feature that makes sense. In those languages, packages simply override code instead of mutating it. However, since a central tenet of arc is to have extreme minimalism, it would be interesting if packages could avoid adding unnecessary bulk to the base language by allowing mutation of existing code.
So, for instance, a package that improves a basic arc language feature could actually "clean out" the previous version of the code right out of the base language. (The packaging system would of course retain a copy of the old code, in case the package is ever removed and the previous code needs to be restored)
Or, a package could just be a patch on a core file (like ac.scm) that enhances the core in some way. This way, a package system could be used even for aggressive language experimentation.
Seems interesting, but I don't know if it could be implemented in a simple manner. I think it would create quite a lot of confusion especially in the following situation: package A requires package B, package C requires a "modified" B, and package D requires both A and C. The conflict doesn't seem solvable, even with namespaces: B and B modified would live in the same namespace, unless the latter modifies also the namespace.
I suggested adding "interfaces" to packages. So A might require <B>v1, while C requires <B>v1-modified. At the very least, loading C would fail if the copy of B available on the user's machine is the original that does not provide <B>v1-modified.
OF course, it still requires that the modified B provide the semantics for the original B so that it provides <B>v1 seamlessly.
Interesting idea, but I'm having a hard time visualizing how it would work. How do you patch source code after it is compiled and being used in a running image? I am aware of the existing (let old foo (def foo (...) (bar (old ...)))) pattern, but you seem to be implying something more that this... Or am I completely off on that aspect of it?
