Fork me on GitHub

Hey team, noob question: is there a mutable implementation of ISeq that I could use? i.e list made of pair data structs. I need this to support an interpreter I’m writing, which unfortunately requires mutable cells. Can create my own Pair data structure with deftype and implement ISeq, but if something exists, would prefer to use it.



👍 2

seqs, by definition, should be persistent (ISeq extends IPersistentCollection)

👍 2

Clojure's core library depends on this assumption - using a mutable seq likely makes Clojure code using it unsafe for multi-threaded use

👍 2
Bob B16:08:06

Clojure's typical mutability construct is the reference type, so you could do, for example, an atom over something that implements ISeq

👍 2

you can however make your custom data structure implement Seqable and then have it return a persistent seq view of the mutable data structure

❤️ 4

implementing that correctly means copying data probably


Awesome context. Thank you team!


I need to make some modifications to a quizzing system I have set up. Right now, it just takes a randomized subset of the possible questions and throws them at the user. But there are a lot of duplicates and it's not all that helpful for questions that are tricksy. So I want to do more of an SRS (spaced-repetition-system) --themed take on it. I think I can just store the timestamp for when the user last got the question right... I already keep track of the number of misses, I'm just wondering what all I need to keep track of.... number-of-misses, last-time-it-was-correct, then somehow prioritize questions based on the #misses and last-🕐-correct. I suppose I also have to decide if getting it correct once totally resets then number of misses, or if it just reduces it by one. I suppose it would be fine to multiply the time differential (- now then) by the number of misses and sort the total set descending by that, and then (take however-many total-set) Seems sane?


Seems sane, but perhaps #off-topic?


@U3ES97LAC have you considered just storing all the answers?

{:session/id 123
 :session/started #inst "..."
 [{:answer/question-id 456
   :answer/correct? true
   :answer/timestamp #inst "..."
   ;; optional ideas:
   :answer/value "..." ;; you can even store the actual answer, if that's relevant
   :answer/certainty 3  ;; since you mentioned SRS, you could in the future model "correct, but wasn't sure"
You can store as much or as little as possible (could even be a simple of vector of tuples [[question-id true/false] ...]). But the advantage of modeling the answers explicitly is you can write those algorithms (frequently-missed-questions, not-asked-in-long-time, etc) on top of this data model and always change your mind later.


@U05476190 not a bad idea. Eventually it will be a lot of data... I like your approach a lot, it might be a bit extra for what is needed but your solution is expansion-friendly 🙂