mylesmegyesi / clojure.core Goto Github PK

The current implementation defines -equivalent? on the IEquivalence protocol. However, clojure uses == only for numbers and will throw a type error without Numbers as arguments.

https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L1059

Persistent Hash Map is very reliant on integer math, and you'll see things like this where integers are added together in clojure. Unfortunately, this implementation relies on + which is currently defined in next. The type output of + when adding integers is Long.

This means that we need a solution for type preserving math operations or something.

Hi,
I've been watching the activity on this repo hoping that one day this could be made into another piace in the tools.reader/tools.analyzer[.jvm]/tools.emitter group of libraries that will help towards a CinC implementation, I like the way this library is going and I am considering starting to contribute when I'll have some free time.

I have a couple of complains though:

• I really don't like the big amount of namespaces that are getting created, there's no point to them, I'd propose grouping all the protocols from each on their own namespace to all the namespaces in a clojure.lang.protocols namespace and all the "wrapping" namespaces in a clojure.core' namespace (e.g get rid of namespaces clojure.lang.deref or clojure.lang.map-entry)
• The current way of creating partial/extensible reimplementations for deftypes looks horrible (sorry :)). I've been down the road of reimplementing the clojure corelib before deciding to focus on the reader/compiler and I wrote neurotic for this purpose, you can see an example of how to define partial implementations reusable in deftypes here and how to actually use it in a deftype here.

What do you think?

when checking equality on an array seq (which uses aseq/seq-equal?) with a seqable (in this a vector) it claims that they are not equal

(require '[clojure.next :as n])
(n/= (n/seq (n/to-array (n/vector 1 2 3))) (n/vector 1 2 3))
; => false
(n/= (n/seq (n/to-array (n/vector 1 2 3))) (n/seq (n/vector 1 2 3))))
; => true

This is a deviation from clojure

(= (seq (to-array (vector 1 2 3))) (vector 1 2 3))
; => true

Type hinting functions (when appropriate) is much faster than using macros so we should use a type hint when it conforms with existing clojure behavior.

It would be nice to have a TravisCI build on each PR

clojure/clojure@dff9600

Use Clojure CLR as a way to tease out what is platform specific and what is not.

We are using a running length value https://github.com/mylesmegyesi/clojure.core/blob/master/src/clj/clojure/lang/persistent_vector.clj#L23

This should instead be a calculated value https://github.com/clojure/clojure/blob/clojure-1.6.0/src/jvm/clojure/lang/PersistentVector.java#L340

it causes the count branch for IPersistentCollection to fail.

The following does not repeat infinitely and will recurse infinitely

(defn repeat
  ([x] (lazy-seq (cons x (repeat x))))
  ([n x] (take n (repeat x))))

but the following does

(defn repeatedly-true []
  (test-seqable '(true (lazy-seq (repeatedly-true)))))

it seems like there is an issue in the realization of lazy seqs