I've never said I want (empty some-map-entry) to implement IMapEntry.
On Sat, Jul 19, 2014 at 10:55 PM, Mike Thvedt wrote:
> Is there a reason you want an (empty some-map-entry) to
> implment IMapEntry? You can already do ordinary modifications on it where
> it loses the type. Not sure why empt
It's worth mentioning that ClojureScript does not have a MapEntry type.
Vectors implement IMapEntry using nth:
https://github.com/clojure/clojurescript/blob/master/src/cljs/cljs/core.cljs#L3601-L3605
And empty returns an empty vector:
ClojureScript:cljs.user> (empty (first {:a 1}))
[]
On Satu
Is there a reason you want an (empty some-map-entry) to implment IMapEntry?
You can already do ordinary modifications on it where it loses the type.
Not sure why empty should be an exception. IMapEntry only provides key,
val, and java.util.Map.MapEntry, and probably if you're modifying map
entr
In *Clojure Programming* (Emerick, Carper, Grand) a swap-pairs function is
defined in the section describing how empty allows you to write functions
against abstractions. That function operates on sequentials, and,
importantly, is carefully designed (invoking empty) so that its return type
is c
I did a little “code archaeology” in an attempt to elucidate what Rich may
had been thinking:
In mid 2007, some of the persistent collection implementations had an EMPTY
value defined. [1, 2]. (But, of course, no such EMPTY value was defined for
MapEntrys.)
Around a year later, MapEntrys were
I understand that, but the issue that bothers me is that MapEntry prints
like a vector and satisfies the clojure.core/vector? predicate. If you call
first or seq or something like that on a map, your REPL will lie to you.
Worse, you might even be 100% aware that you have a MapEntry instead of a
You cannot have an empty MapEntry though, because map entries always have
just one size, a key and a value. I can definitely see how it can be
confusing though.
On Sat, Jul 19, 2014 at 4:42 PM, Brandon Bloom
wrote:
> I've been bitten by all three of these things in the past:
>
> 1) A MapEntry l
I've been bitten by all three of these things in the past:
1) A MapEntry looks like a vector, but isn't.
2) Two element vectors can't be used as map entries.
3) Applying empty to a MapEntry returns nil.
On Saturday, July 19, 2014 4:04:13 PM UTC-4, Jozef Wagner wrote:
>
> While the c.l.MapEntry is
While the c.l.MapEntry is a persistent vector, there is no such thing as an
empty MapEntry persistent vector. Returning empty HAMT persistent vector
instead is not a good solution, as 2 elements HAMT vector does not
implement IMapEntry interface.
One approach on how to solve this is in Zach's c
As Mike points out, it does seem that MapEntry is considered a collection
and is designed to emulate a vector so that you don't really have to worry
about whether you have a MapEntry or a two-element vector (and as he points
out, in ClojureScript there really is no distinction between a MapEntry an
MapEntry is a collection:
(coll? (clojure.lang.MapEntry. "a" 1))
;=> true
(ancestors (class (clojure.lang.MapEntry. "a" 1)))
;=> (a set that includes clojure.lang.IPersistentCollection)
The docstring for empty implies it would return an empty MapEntry. But
perhaps since MapEntry is a specia
What does `empty` do for non-collection types?:
(empty 1) => nil
(empty "123") => nil
(empty :abc) => nil
(empty (clojure.lang.MapEntry. "a" 1))
So it is actually very consistent.
On Fri, Jul 18, 2014 at 6:06 PM, Brian Craft wrote:
> hm, looks even more broken in the context of these examples
hm, looks even more broken in the context of these examples.
On Friday, July 18, 2014 5:04:34 AM UTC-7, Mike Fikes wrote:
>
> My guess: Perhaps this is a bug, or alternatively, a known issue that
> won't be addressed because to do so would be a breaking change.
>
> There is an old demo of Clojure
While MapEntry is displayed as a vector it isn't actually a collection
(which is a mistake I sometimes make also), so empty behaves as expected.
On Friday, 18 July 2014 10:45:19 UTC+1, Brian Craft wrote:
>
> => (empty [:foo 5])
> []
> => (first (mapv identity {:foo 5}))
> [:foo 5]
> => (empty (fi
My guess: Perhaps this is a bug, or alternatively, a known issue that won't
be addressed because to do so would be a breaking change.
There is an old demo of Clojure given by Rich where MapEntry's were printed
using some sort of un-readable notation #<:foo 5>. But clearly MapEntry's
have been r
On Jul 18, 2014, at 5:45 AM, Brian Craft wrote:
> => (empty [:foo 5])
> []
> => (first (mapv identity {:foo 5}))
> [:foo 5]
> => (empty (first (mapv identity {:foo 5})))
> nil
=> (class (first (mapv identity {:foo 5})))
clojure.lang.MapEntry
=> (class (first (mapv (fn [[k v]] [k v]) {:foo 5})))
=> (empty [:foo 5])
[]
=> (first (mapv identity {:foo 5}))
[:foo 5]
=> (empty (first (mapv identity {:foo 5})))
nil
What just happened there? Is this expected? In the second and third cases
the type of the vector is clojure.lang.MapEntry, which I expect is the root
of the behavior, but this seem
17 matches
Mail list logo
