big red alert on this, adding core.async "because you have been wanting to use it" is a terrible idea

in my experience, on a given project where core.async is introduced, more bugs are introduced than features and invariably the library is used incorrectly

by using core.async you discard a number of clojure features, excellent ones you might not even have names for yet until you use core.async and find them missing

to me "I'm adding core.async because I've been meaning to use it" is like "I'm bringing dynamite to the construction site because I think explosions are cool"

I like-a things go BOOM ^.^ (your points are noted)

this solution will introduce intermediate collections as a result of map-indexed, map and lastly remove. I can suggest - (count (take-while #(not= "dead" (first %))))

it is not matching with your result thou, but can give you a hint

user=> (def x '(["gabriel" 158] ["s" 127] ["aunt" 102] ["dead" 3]))
#'user/x
user=> (first (keep-indexed #(if (= "dead" (first %2)) %1) x))
3
user=> (first (keep-indexed #(if (= "YYY" (first %2)) %1) x))
nil

anytime i see map and remove nil? it’s likely better as a keep

Thank you! Didn't realise keep-indexed was a thing and haven't really used take-while (and also just didn't know how to approach the problem better)

if performance is an issue, you’re going to want a diff data structurue than that list, btw

the only way i know how to be aware of all these functions is to read the “dictionary”, so to speak: https://clojure.org/api/cheatsheet

@UUSQHP535 If you're going to do that lookup more than once on that dataset, I suggest you use an associative data-structure (for the performance benefit). Even if you're only going to do that lookup once, I would still change the data-structure (to help the reader quickly understand your intent).

(let [data [["gabriel" 158] ["s" 127] ["aunt" 102] ["dead" 3]]
      words->idx (zipmap (map first data) (range))]
  (words->idx "dead"))

I think the only time it doesn't make sense, is if you are looking to solve this lazily without rebuilding the entire datastructure in memory (think lazy-loaded sequences or infinite lists)

I also have a sneaking suspicion that this code is accidentally non-idiomatic:

`(["gabriel" 158] ["s" 127] ["aunt" 102] ["dead" 3])

I'm not sure if you wanted to search in both the first and second collection if so this is one way:

(->> '(["gabriel" 158] ["s" 127] ["aunt" 102] ["dead" 3])
      (keep-indexed
       (fn [idx item]
         (when-let [idx2 (->> item
                              (keep-indexed
                               #(when (#{"dead"} %2) %1))
                              first)]
           [idx idx2])))
      first)

But... ya the outer list doesn't really make sense to me, a list is not even an indexed data-structure, probably best to at least make it a vector.

And you can generalize it like so:

(defn index-of
   ([element coll]
    (index-of element coll []))
   ([element coll idxs]
    (->> coll
         (keep-indexed
          (fn [idx item]
            (if (sequential? item)
              (index-of element item (conj idxs idx))
              (when (= element item) (conj idxs idx)))))
         first)))

(def data [["gabriel" 158] ["s" 127] ["aunt" 102] ["dead" 3]])

(index-of "dead" data)
;;=> [3 0]

(->> (index-of "dead" data)
     (get-in data))
;;=> "dead"

if you have a tutorial/readme telling you to add a dependency in leiningen that looks like this

[abc/def "1.2.3"]

you can put it into the :deps map like this

{abc/def {:mvn/version "1.2.3"}}

here https://github.com/clojure/contrib-api-doc/blob/master/cli/example-deps.edn#L21 it excepts the maven version, I did not see any which has only leinginen deps

in the project.clj we can add, but I am not sure in edn file

lein deps are maven deps. The org.clojure part is the maven group id, the clojure part is the artefact id, and the "1.9.0-RC1" part is the maven version. In a lein project.clj file, that is written as [org.clojure/clojure "1.9.0-RC1"] and in a tools.deps deps.edn file, that's written org.clojure/clojure {:mvn/version "1.9.0-RC1"} but both will resolve the same artefact from maven central.

oh ok, good information, that helped !

the deps.edn file also supports more than just maven dependencies, which is why it has to differentiate between the type of thing you're trying to depend on

What kind of thing are you trying to do with said bytes?

You can checkout https://github.com/ztellman/gloss/wiki/Introduction by Zach Tellman.

@U7ZL911B3 turn strings into them and manipulate them a bit & I could use something like Ruby's pack https://ruby-doc.org/core-3.0.2/Array.html#method-i-pack

gloss seems like it could be useful, thanks!