"The new language construct is much more lightweight than any code we might have written purely at the application level, even with Lisp macros."
The new language construct...
-(def editor ((o u the.me))
+(def editor ((t u me))
As language changes go, this is only slightly better than the change of using a short name.
Like, every time you type "fn" you could have typed "lambda", and that is indeed a certain kind of inconvenience.
In this case, every time you type "(t" you could have typed "(o" and "the." instead. So it has the slight benefits of a shorter name, and it has the added benefit that it makes you move your cursor less. (On the other hand, if you're refactoring an existing use of "(o", it makes you move your cursor more.)
This is the kind of thing I consider macro-expressible, rather than a language innovation. Libraries should be able to provide this. And in fact they can; my Lathe libraries have customizable pattern matching support already.
Yeah, Arc macros can't update the built-in pattern-matching syntax this way. My library does it by implementing its own special version of (fn ...) and such. For Hacker News in particular, it might have been easier to add (t ...) to the language rather than to overhaul the design of pattern-matching throughout the codebase to be extensible.
"You still have to declare which variables you plan to use in each function signature, so it's possible to look at the function and know exactly what state it depends on."
That's not even true. A call to (user-name ...) still depends on the state of the.me, and that's no longer visible in the signature.
It worries me that static knowledge would be used as a justification for this technique when the knowledge isn't even sound. That's where we get arbitrary language restrictions that have no real benefit.
I hope this static knowledge is meaningful in some weaker way that just wasn't quite articulated here.
To the author: I'm sorry I'm railing on this. I appreciate the information about how Arc's doing.