Fork me on GitHub
#clojure-dev
<
2019-05-10
>
jimmy00:05:03

Knowing nothing about this, it seems like making transients iterable would make it possible without changes to RT. But not sure if that would be a good idea or not.

ghadi00:05:09

expanding the scope of what transients are capable of is generally a bad direction

ghadi00:05:07

if you're passing transients to code that isn't aware of them, that's almost certainly a design error

ghadi00:05:58

things you can do to various transients: update them (conj! / assoc! / pop! / disj! ) graduate them (persistent!) get (get / lookup) count them

seancorfield00:05:11

Yeah, my understanding of transient/persistent is that the scope has always been intended to be very minimal

seancorfield00:05:52

I was disappointed the other day that I couldn't update one 🙂

ghadi00:05:40

same deal as with empty? -- you can update them with your own function

ghadi01:05:05

but ya can't pass them to generic code that isn't aware of transients

seancorfield01:05:37

Yeah, my first reaction was "Aww!" and then I was like, "No, that makes perfect sense..." and I just assoc!'d in an updated value 🙂

seancorfield01:05:15

After nine years of using Clojure, I don't question core decisions anywhere near as much as I used to 🙂

gfredericks01:05:18

update! should be easily writable though

seancorfield01:05:32

17 lines of code with ! added in the appropriate places 🙂 But each of those functions add up. And I only needed a specific arity (and it's the first time I've wanted update! in all those years).

devn01:05:02

@jimmy yes, i wrote that on the ticket

devn01:05:43

the options seem to be implement iterable or cond in empty? to do the (zero? (count coll)) for TransientCollections. Mike fikes has proposed the latter on the CLJS side.

ghadi02:05:11

this is a bad idea devin

ghadi02:05:30

empty? == (not (seq )) transients aren't seqs

devn02:05:42

Are Arrays?

ghadi02:05:50

are arrays what?

devn02:05:19

(seq (java.util.ArrayList. [1 2]))

ghadi02:05:49

transients are designed to have a limited amount of operations to work on them

ghadi02:05:54

seq isn't one of them

ghadi02:05:14

user=> (seq (transient []))
Execution error (IllegalArgumentException) at user/eval143 (REPL:1).
Don't know how to create ISeq from: clojure.lang.PersistentVector$TransientVector

devn02:05:25

I'm well aware

ghadi02:05:54

(i think it's a bad idea to make empty? work on transients in clojurescript as well)

ghadi02:05:36

(I think this issue is distinct from the issue of contains? being broken on transients - https://dev.clojure.org/jira/browse/CLJ-700 , as find already works on transients, so why shouldn't contains?)

ghadi02:05:11

empty? has a particular implementation, fwiw, and I don't see it changing

devn02:05:02

Yes, this is a separate issue. That is also noted on the empty? ticket.

ghadi02:05:44

I guess I mean it's different in nature: one is a busted impl, one is enlarging the contract of transient

devn02:05:59

https://dev.clojure.org/jira/browse/CLJ-1872 ticket is here if you're interested in adding your opinion. The short list of operations supported on transients makes sense, sure. You can add and remove things, get a value at a position, check for the existence of a value or values across vec/set/map, count them. All those fun things. Truth of the matter is I don't necessarily disagree with you, but I found myself at the contains? issue while poking around in JIRA today, and then found my way over to this ticket. The ticket is currently listed as a defect with critical priority. It was triaged and vetted. Were it not for these things, I may not have spent any time looking at it.

dominicm06:05:32

A bounded-count would be fine on lazy sequences

dominicm06:05:57

Seems reasonable to me to check whether the transient you're dealing with is empty.

gfredericks10:05:46

I forgot about bounded-count

gfredericks10:05:07

it already works on transients too

devn20:05:44

I'm not sure I follow. Transients are counted?, and so bounded-count simply calls count on the transient.

seancorfield21:05:50

@devn I think that was just in response to the comment about not being able to define empty? in terms of count because of potentially infinite lazy sequences...?

seancorfield21:05:04

(so it could be defined in terms of bounded-count)

devn22:05:12

ah, I see.