Most of Clojure's collections already can hold arbitrary type values inside of them, with no additional work required, whether those types are built into Clojure or not. That is because most collections treat all contained items as Java Object references.
The only exceptions I can think of are the few Clojure data structures that were developed to save memory, and perhaps also improve performance, by avoiding the Object references and holding Java primitive types directly, e.g. (vector-of :int 1 2 3) The tricky part is not that, but getting a new number type to be operated upon by existing Clojure math operators like + - * / Andy On Tue, Apr 28, 2015 at 7:20 AM, Nik <nkripl...@gmail.com> wrote: > To put is simply, it would be nice to have a complex type in Clojure, not > as a separate namespace, but something that is part of the language. It > should interoperate with other Clojure types (like adding a double to a > complex), as well as clojure.core.arithmetic. That's what I meant about > playing nicely with collections - it should not matter that there is a > complex type in a collection. The arithmetic operations on collections > should work regardless. Sorry for the confusion. I will spend some time > looking into the modifications needed to clojure.core to accomplish this. > > I could be wrong but it seemed to me that Alex was suggesting there might > be a way to open up the type system so that others can add types "easily". > > Also, I didn't mean to imply that I don't care about performance. It does > matter, but if Clojure doesn't have Fortran-like speeds, then that is fine > with me. Unfortunately, at this point I can't be more specific about > performance - in either absolute or relative terms. > > > On Tuesday, April 28, 2015 at 8:35:39 AM UTC-4, Gary Verhaegen wrote: >> >> Your messages are a bit confusing. Playing nice with collection functions >> would depend on the collection, not on its contents. >> >> Maybe you could elaborate a bit more on what you're trying to accomplish? >> >> If you do not care about performance, you need to decide whether you want >> your type to work with clojure.core arithmetic operators, which from Alex's >> comments would seem to require modifying Clojure itself, or if it would be >> acceptable to you to define your own operators in your own namespace (which >> could check the type and default to the clojure.core versions, providing >> some transparency in exchange for some performance). Of course, you then >> have to worry about other functions that maybe call clojure.core operators >> indirectly, and the bahavior of functions such as min and max. >> >>> >>> -- > 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 > Note that posts from new members are moderated - please be patient with > your first post. > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
