On Feb 25, 2009, at 16:32, Jeffrey Straszheim wrote: > Is there any reason they cannot be implemented as structs with some > sort of type tag?
I suspect that could be done, but some nice features would be lost: 1) User-friendly printing. I implement the multimethods print-method and print-dup for my classes, which allows me to specify how objects are printed. print- method and print-dup dispatch on class, so my types need to be classes or at least derive from a class that is distinct from the standard Clojure data structures. Consider how the simple tree structure a-tree would print if structs with type tags were used for implementation! With my class-based implementation, I could even define a specific printing method for each individual type, and I expect to do that sooner or later. 2) Usability in multimethods The above argument illustrates a more general problem: multimethods meant for use with a wide range of data structures can in practice only use class as a selector, as that is the only one that will work for the built-in data structures. Look at fmap in clojure.contrib.types.examples, for instance. It would make sense to add an implementation for maps that applys f to the value of each map entry. But I can't have that plus a type system based on maps with special tags - it's one or the other. 3) Usability in type hints With types implemented as classes, they can be used in type hints on function arguments. While I don't expect any performance gains in this case, it is quite useful as a development aid. 4) Modularity There are bound to be several type or class systems for Clojure, as for other Lisps. We already have Spinoza, for example. If all these systems use maps with type tags, there are bound to be tag conflicts sooner or later. For example, someone will create a Spinoza class with a slot whose name interferes with my special type tag. This can't happen with my closure-based implementation. It creates objects that are distinct by the very nature of their classes, so it doesn't interfere with whatever someone else may come up with. Konrad. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
