With defrule and in akkartik's python-like keyword arguments (http://arclanguage.com/item?id=12657), argument names become significant. Normally you're free to change the names of arguments, for instance because you didn't put enough thought into them first time around. Is it a problem to start treating argument names as a set-in-stone kind of thing? I mean, you never know which args someone is going to rely on not changing, so the names become part of the public interface.
An alternative to public interfaces is to not treat any part of your code as set-in-stone, but instead to improve your code whenever you think of something better -- such as using better argument names as you come up with them.
The traditional assumption is that if I'm using your code and you change it, I'll find it hard and difficult to change my code to use your new version, and so you should put time and effort into coming up with things like stable public interfaces -- things that you wouldn't otherwise do for yourself, but things that you think will help me.
However, using a powerful language such as Arc I've found easy to change my code to make it work with new releases. For example, the home page of arclanguage.org says "Expect change. Arc is still fluid and future releases are guaranteed to break all your code." Which sounds pretty dire. Yet in practice I've easily rebased my code on every release of Arc since arc0.
Easier in fact for me than my experience using other languages that strive to maintain compatibility with earlier versions -- their libraries end up having so many layers and compatibility modes that it becomes tedious for me to figure out what they're doing and where their bugs are.
