>clojure.lang.Cons follows what CL's cons does with exactly one deviation: cdr must implement clojure.lang.ISeq
Well then, it's not a cons, is it? It's actually a particularly weird implementation of push, which stores the pushed item in another cell. If you're not going to put cons in your language, fine, but be honest about it.
>Further, when I'm using deftype, if I implement the right interfaces, the core clojure sequence functions like conj, first, rest, map, filter, reduce, etc will all work on my custom type, without me inventing a namespace worth of custom implementations for those
So you have high-level collection functions that act the same between collections? Good for you guys. Lisp and scheme have had that for ages. But don't call your high-level functions by the name the low-level functions are expected to be called, and expose those low-level functions: sometimes a function wants to know what sort of structure it's manipulating.
>Clojure code isn't written using Lists, Vectors, Strings, Maps, Keywords, and Symbols? I guess I'll stop writing macros then. No clue how they ever managed to work.
Okay, yeah, I miswrote that, it doesn't violate homoiconicity. But I disagree vehemently about the reader. Assuming the readtable is in the same state, anything you write out can be read back in to give the same structure in RAM: that's why you can use write to serialize state.
Also, by the above, clojure violates commutative equality, which is bad in any language that claims to support FP: If a property is false on an entity, than an entity that entity is equal to cannot have that property be true. Otherwise, they're not equal.
Well then, it's not a cons, is it? It's actually a particularly weird implementation of push, which stores the pushed item in another cell. If you're not going to put cons in your language, fine, but be honest about it.
>Further, when I'm using deftype, if I implement the right interfaces, the core clojure sequence functions like conj, first, rest, map, filter, reduce, etc will all work on my custom type, without me inventing a namespace worth of custom implementations for those
So you have high-level collection functions that act the same between collections? Good for you guys. Lisp and scheme have had that for ages. But don't call your high-level functions by the name the low-level functions are expected to be called, and expose those low-level functions: sometimes a function wants to know what sort of structure it's manipulating.
>Clojure code isn't written using Lists, Vectors, Strings, Maps, Keywords, and Symbols? I guess I'll stop writing macros then. No clue how they ever managed to work.
Okay, yeah, I miswrote that, it doesn't violate homoiconicity. But I disagree vehemently about the reader. Assuming the readtable is in the same state, anything you write out can be read back in to give the same structure in RAM: that's why you can use write to serialize state.
Also, by the above, clojure violates commutative equality, which is bad in any language that claims to support FP: If a property is false on an entity, than an entity that entity is equal to cannot have that property be true. Otherwise, they're not equal.