yes, make wrappers. Might probably want to include wrappers for pr and prn too.
If you're using nex-3's arc-wiki.git (also called the "Anarki") there is a 'redef form which allows you to wrap easily.
Also, on arc-wiki there are two implementations of the same way to add a bit of OO in Arc, in lib/settable-fn.arc and lib/settable-fn2.arc. See also my series of "Create your own collection":
edit: ps: some arc built-in features - function argument destructuring comes to mind - won't use the Arc redefined 'car 'cdr etc, but will use the underlying mzscheme methods, I think. Caveat Emptor!
The difference lies mostly in what the use of the type in 'annotate is. nex-3 views this type as the "real" type, with any "claimed" (user-interface) type ducked by overloading 'isa. I view this type as the "claimed" (user-interface) type, with the "real" type being the underlying implementation (usually a function) for this.
Very minor nitpick: "nex3". The hyphen is only in my URL because nex3.com was taken :-p.
Also, I don't like overriding isa; it's just necessary sometimes because the standard libs aren't really geared towards duck typing. I much prefer overriding basic functions and having more complex functions assume those base functions will work. This is really what duck typing (as I understand it) is all about.
^^; lol. I think I've been rather consistently calling you nex-3 with a hyphen O.O;
The problem, I suppose, is the rather inconsistent formalization/nonformalization of type classes/interfaces/hindley-milner typesystem. In Ruby it's informal - you just say this or that object has this or that function which will just work, in the expected manner. In Haskell and Java it's formal - you say this type provides this type class or presents this interface, and must therefore have this or that function which must work, in the expected manner.
annotated types are kinda like a formal type class, except existing type classes are not trivially extendable except informally (via redef).
Yeah, I think that's right. And I think Arc should go the path of informality, for a couple reasons. First, it's dynamically typed, and duck typing (or informal typing) has historically worked well with dynamically-typed languages (with Ruby, Python, and maybe Smalltalk). CLOS also tends to that side of the spectrum, although I'm not sure how explicitly it embraces duck typing.
Second, and I think more importantly, duck typing gives the programmer more power, in exchange for more opportunity to screw stuff up. This is very much in line with Arc's philosophy.
Using formal interfaces, both the people writing the polymorphic code and the people writing the polymorphic objects have to explicitly code polymorphically. Using informal interfaces, only the people writing polymorphic objects have to be explicit. The other people can* be aware of the polymorphism, which allows powerful stuff like Ruby's Enumerable module, but as long as the objects behave correctly ("quack like a duck"), you can use pass them to code that doesn't expect them at all and they'll still work.
* I know less about Smalltalk than I want to, so I don't know how much it makes use of duck typing.
Here's another interesting bit: car and cdr could be modified into settable-fn's and their defset's could be completely removed from arc.arc ^^. Also, it should be possible to additionally modify compose to work on the '= attachments ^^.
