Erm... he recommends using intended types as explicit arguments? Like, (coerce my-list 'list 'string) and (equivalent list1 list2 'list)? Sounds a lot like the kind of "Time time = new Time();" redundancy you get in Java-like blubs. ^_^
I do think it's a more consistent approach, and I usually side with what's consistent, but here I think we can do way better.
How about another technique Java uses: There's a single standard equals() method for non-reference comparison, and it has a custom specification for each type. There's no need to disagree with it, 'cause you can create a wrapper object with custom implementations of equals() and hashCode() and use that to wrap all your Map keys, etc.
In a language like Arc, this would create code of the form (coerce (annotate 'list my-list) 'string) instead. However, 'my-list can be wrapped up as a 'list once in order to keep the rest of its uses brief.
Another lesson to take from that article besides the one it promotes is to refrain from having values like nil which can be seen as being multiple types. If lists were all tagged 'list in the first place, it would be obvious which code was responsible for tagging them. The biggest drawback, I think, would be that each procedure which returned a new list would have to allocate a wrapper for that list. (But then that's only a performance issue.)
The other obvious objection is that (if my-list ...) wouldn't check the list for emptiness. Well... I like that idea, myself. People can always say (if empty.my-list ...) to test collections, and Arc programmers already have to do that now for strings and tables.
