I'd go with the same approach. The window approach will be both slower and less obvious in its implementation.

Agreed. You could try to do something like this, but it's awfully complex just to handle the degenerate case of a radius of 1 (the radius input is ignored) and returns the wrong answers for both the last element of the vector and an element that is not in the vector. Those can be resolved, but that's even more complexity.

(defn window [m ctr r]
    (reduce (fn [a v]
              (cond
                (= v ctr) (vector a v)
                (vector? a) (reduced (vector (first a) v))
                :default v))
            nil
            m))

cool, I went with

(defn adjacent-elements
  [v e]
  (let [i (.indexOf v e)]
    (if (< i 0)
      [nil nil]
      [(get v (dec i)) (get v (inc i))])))

Eyeballing that, you probably want to check the end of vector case too

get will return nil if the index is out of bounds.

I've a feeling that Christophe Grand's xforms library has some windowing functions.

https://github.com/cgrand/xforms/blob/62375212a8604daad631c9024e9dbe1db4ec276b/src/net/cgrand/xforms.cljc#L518

Maybe that's useful for a generalized window with a radius of n?

This only works in cljs, there's a JIRA about this for cljs to support #? so you can do different implementations as required.

I have seen that ticket, but that seems to be a separate issue. I've done cross-platform readers without that multiple times, just never noticed the read-string behavior

to be clear, a literal #ordered/map [] in the source code works this way in clj and cljs just fine

To be clear, Clojure doesn't really support returning a quoted for from a tagged reader in order to return an object.

and yet it's behavior I rely on daily

Clojure does evaluate the quoted form when you return it from a reader literal

Right, but that's not the intended usage afaik.

Interesting, this is news to me.

worked around it as such, which does break in some edge cases, but all in all works fairly well

(defn ordered-map-reader [coll]
  (if (some-> (resolve 'cljs.env/*compiler*) deref)
    `(ordered-map ~(vec coll))
    (ordered-map coll)))

heh, funky

data reader functions should return data, not code

(in Clojure)

objects are a kind of data, right? 😛 (e.g. uuids)

yes

you are reading a value - return the value

so cross platform reader conditionals are not officially supported?

No. ClojureScript has different considerations due to serialization.

I belive you can support cljs in this way by extending a multi-method in cljs.analyzer somewhere

people are doing it in practice though, see for instance https://github.com/henryw374/time-literals

Right, but in an effort to make that actually work Henry is pursuing the aforementioned cljs jira ticket.

I can't speak to the cljs concerns, I'm just telling you the Clojure expectations. I'm not sure anyone has actually intentionally considered the design constraints around portable data readers.

in general, reading does not imply eval (particularly with edn, which is only about reading). the idea is that during read, you can pluggably read a data value that has a tagged literal representation

data readers in clojure are not macros, and don't have eval (even though you may eval the resulting read value later and this may thus incidentally result in some cases in a value after eval)

thanks for clarifying, Alex. That makes sense.

I feel the conceptual model breaks down. I don't think it's that simple. You can execute code in a data_reader, like if you extend edn to parse tagged literal, it's your responsibility now to be sure it can't execute insecure code. And you're expected to execute code as well, since you need to return a in-memory structure from the read form.

I think the issue is just that what is available from the environment at that time is simply undefined it seems.

the job of a data reader is to take a tagged literal and return a value

I don't know what is ambiguous about the "environment" and if you're doing anything that requires anything of the environment beyond the tagged form, you're probably doing something you shouldn't.

Well, I mean that taking a form and returning a value from it does involve code execution. What isn't well defined is what that code can expect to depend on. So like in the example, can it depend on the current Clojure runtime? And switch on if Clojure or ClojureScript? Or is this considered out of reach for the code creating the value?

well you're evaluating the function in the runtime so I would think you could depend on it

how could it not depend on the runtime

maybe I just don't understand what you're asking

I think my question is, is there supposed to be a convention that dictates that a data_reader function should be a pure deterministic function? Or is it fine to say create a #time :now that would read from the system clock, or a #slurp "./file"that would read from the file. Etc. And similarly say something that would check a global and return a different value based on it, like checking if the compiler is ClojureScript, if we're running under prod or devo, etc.

is "now" a value?

I think most things you mention sound like bad ideas for tagged literals :)

but Clojure assumes you can make your own decisions :)

Haha, ya that last part is what I was wondering.

cool, it's not just me who would like data_readers.cljc documented then 🙂 https://github.com/clojure/clojurescript-site/issues/371

Maybe an example?

Or more description of what you’re trying to do?

ooooh you want to dispatch to a threadlocal-defined fn?

No you can't, yes that is ridiculous

what the… you want every thread to behave differently?

yeah if that’s what you want, just define a different fn for every thread to run

..... walk back -- why are you wanting to do this in the first place?

testing concern?

I’ve got some legacy code that extends the clojure.java.jdbc/IResultSetReadColumn in a way to handle ora timestamps but it doesn’t handle timezones gracefully (assumes DB timestamp is in same tz as localhost)

this logic is used in a number of places so it’s not easy to refactor safely at the moment. That’s ok, thanks for comments all!

Your description is a little vague, but if you need a shim via threadlocal, you could set a dynavar *use-special-timestamp-convert* via with-bindings and have your IResultSetReadColumn implementation check that var.

Cannot recommend that for normal usage, but it might get you out of a jam.

@U9BTYPZCZ You could solve that by using next.jdbc for some queries, since it has a more adaptable API. You can create a adapter for a result set builder that can choose to process column values differently.

At work, we have both clojure.java.jdbc and next.jdbc in the same codebase. You have to be careful about transactions (see the migration guide) but it's eminently workable.

(and in next.jdbc the ReadableColumn protocol is extensible via metadata so a builder adapter's column reader can wrap/annotate column values before read-column-by-index is called)