I did an experiment where annotate produced a list, of the form ('tagged x type1 type2 ...), making the tagged lists transparent objects to the arc system. In doing so, I extended the type system to include the original type of the object in the list and support more than one type, allowing a simple form of inheritance through coercion. I.e. if you annotated a list as type 'foo, until you defined an actual coercion method for converting 'foo to a cons it would be treated as a normal list, and you wouldn't lose any ability to work with it using existing operations.
The thing that annoys me the most about arc's current type system is that if you tag something, it becomes an unusable vector according to all existing arc code, so you need to re-implement or extend any function that you actually want to support the new type.
I think he made the additional change of delegating all functional calls to the "parent" type when they didn't explicitly handle the type at hand. This makes a lot of sense. If you have a list that's tagged 'foo, it should behave exactly like a normal list does until you've specified some diverging behavior for type 'foo.
Do you still have the code for your experiment, shader?
Like I said, it hardly matters to me 'cause of the [annotate 'vector _] workaround.
More worthwhile would be having custom 'iso hashing and stuff like that. ^_^ That's something that would probably benefit from a dedicated Racket type for tagged values, but that's not necessarily the only way to go about it. I'm still trying to figure out how to go about it for Penknife....
