Okay, so... one thing I didn't emphasize in this post is that this lets you write core Arc functions in Arc itself... Like cons, table, instring. Stuff like that. So here's my first partial crack at it:
(def attr (x . args)
(apply (annotate 'fn x) args))
(def cons (x y)
(annotate 'cons
(fn (m)
(case m
'len (+ (len y) 1)
'car x
'cdr y))))
(def car (x)
(attr x 'car))
(def cdr (x)
(attr x 'cdr))
(def table ()
(let alist '((nil nil))
(annotate 'table
(fn (m k v)
(case m
'keys (map [car _] alist)
'get (alist k v)
'set (sref alist k v))))))
(def keys (x)
(attr (coerce x 'table) 'keys))
(def len (x)
(case type.x
'cons (attr x 'len)
'table (len (keys x))))
(def vals (x)
(map [x _] (keys x)))
Note: this is assuming py-arc, and also assuming the message-passing idea.
It's untested, and py-arc doesn't actually support my idea (yet), so I might not be testing it anytime soon. As such, there's probably bugs in it. But it should give you a taste of the power of this idea: the ability to define core datatypes in Arc itself, using only functions (no piggybacking!), but do so in a way that it's easy for user code to extend.
As a side note, what's with the attr function? Well, you see, when Arc sees (my-table 'foo) it expands it to (my-table 'get 'foo), so calling (my-table 'keys) doesn't work. But by annotating the table with type 'fn, you can get at the actual "hidden" attributes, like 'keys, 'get, and 'set. This means that (my-table 'keys) will never conflict with (my-tables 'get 'keys).
Also, I'll note that this is probably significantly slower than having these things defined in Racket, but that's okay. It's nice to know that Arc has the possibility to define them, even if they're defined in Racket (for the sake of performance).
