Maybe try putting the (import ...) call inside the conditional branch?

You could do the same thing you'd do in java? (.newInstance (Class/forName "..."))

answering to myself - :tag should be a fully qualified symbol, e.g. {:tag 'io.opentelemetry.api.metrics.ObservableLongMeasurement}, kudos to @U07FP7QJ0

And if this is because this is how sets work in java. What is the rational in java?

nil is just a value. there is no reason to treat it differently imho

That's right. I'm just wondering if Nil has ever been good to anyone in a set :)

the rationale is: collections are heterogeneous collections of values and everything composes

(but admittedly nils in sets are rarely helpful)

It has been useful for me. For example let us say you have a vector of maps, and you want to check all of the distinct values for some key, and not all of the maps have the key.

If it wasn't possible to have nil in those sets it would just be completely bizarre and arbitrary

the problem with nil (or false) in sets is that containment checks return a logically false value both when the nil/false is found and when they are not found

@U08JKUHA9 i would use (every? key coll-of-maps)

Is that if you just want to use the set as a function directly and not use the contains? function?

That doesn't do the same thing though, you are assuming my intention but that wasn't it

yes (remove my-set items) etc

Yea I see, I guess I've mostly avoided using sets that way

I am happy to know that there are use-cases where nil in set is useful. I often do something like this (empty? (set (map :d [{:a 1 :b 2} {:a 3} {:a 4 :b 5}]))) and when I forgot (filter identity ...) it usually leads to some bug 🙂

Too late now of course, but I wonder if having the IFn implementation of set be like contains? would be more useful than the current version where it returns itself?

Jakub for that one you could consider using keep instead of map initially

So my feeling that there is a better way was right 😅

or (every? #(contains? % :d) [{:a 1 :b 2} {:a 3} {:a 4 :b 5}]) to avoid set creation

@U04V4KLKC I need that set, using keep is a best solution in my case.

https://clojuredocs.org/clojure.core/with-bindings

that only works for vars that are ^:dynamic, right?

Yeah.

in my case I want to change a non-dynamic thing

I guess something like

(defn rebind [^clojure.lang.Var v f]
  (let [old (.getRawRoot v)]
    (.bindRoot v (f old))))

once I saw this gist https://gist.github.com/gfredericks/7143494 which probably later was extracted to a lib https://github.com/mourjo/dynamic-redef

not quite…

@U076FM90B thanks, that looks more like it!

That is a pretty solution.

@U5H74UNSF your rebind is basically what with-redefs also does, it's equally non-thread-safe (but should be good for testing purposes)

why do you need this?

aliases are specific to the namespace context you are in. tagged literals can potentially be read from any namespace. so those two things seem at odds to me.

There are a few libraries that include a data_readers.clj file. Because the Clojure documentation requires this, they are generally namespaced – but because nobody wants to work with excessively long names, these namespaces are generally extremely short, often one common word. To make up an imaginary example, if someone wrote an HTML library that uses readers, under common conventions their tags might be things like #html/element. Personally, I'm not a fan of short namespaces like this – I think there's a high risk of collision, which feels particularly uncomfy for things that are loaded automatically whenever they're present on the classpath. I'm noodling on the idea that improving the ergonomics of working with more deeply qualified namespaces on tags may make it feel a little safer to bundle readers into libraries. To answer your question, this isn't really something I need, but more of an experiment. To me, it feels pretty natural to declare a namespace alias at the top of my file and then use that alias in reader tags throughout. I'd even say it's counterintuitive (subjectively, to me) that this doesn't work. I'm having trouble seeing where the tension would be in this functionality.

so you're talking about the qualifier on the tags, not on the impl

Correct. When defined – whether in a data_readers.clj file, or by binding the dynamic var – they'd still be fully qualified. But resolution would become sensitive to the aliases that are in effect in the context where they're read.

Not in principle different (...I think) from how vars in namespaces are always in themselves fully qualified, but may be referred to through aliases

I think the issue is with when these things are resolved. tagged literals are resolved at read time. the reader does have access to the current context namespace aliases (via the mechanism for resolving autoresolved kws), but that raises the bar for some kinds of tooling. symbols are resolved at compile or eval time (so later).

Ah hm, I didn't realize symbols weren't resolved at read time. Possibly the prototypes I've been playing with won't work as soon as I move out of the REPL.

I think there is some tension here with the goal of tagged literals too, which is to NOT tie tags necessarily to implementation details (the data_readers file is the binding mechanism there)

Actually wait, I did realize that :thinking_face: I'm mixing myself up by thinking of syntax-quotes, which do (I think?) resolve at compile time

er, read time

What in this ties the tags to implementation details? I'm thinking of this analogously to :as-alias, where it's just a way to declare a shorthand which may or may not relate to a namespace where any actual code lives.

In practice it may even be used mostly with as-alias

I don't know, I think this needs problem clarification before getting to this level

Fair enough, thanks for sharing your perspective. My immediate goal here is to build a prototype I can play with to see how it feels and what problems may arise. If it seems fine and I release it into the wild, I'll definitely make sure the README is festooned with warnings that the usage patterns it enables are experimental and may have undiscovered design issues.

What’s your question?

I have two structures that are quite different, say [{:a 2 :b: 3}] and [{:foo "bar"}] - I see the diff sometimes having the :- (remove), sometimes only having :r in it. I am not sure if I am doing something wrong or the diff is not deterministic...but the :- is very nice when you want to post-process the diff and, say, remove entities from the database

the algorithm is determistic, the same pair of data will have the same diff

right, thank you that's a good correction of wording

I hope the issue is clear enough though

they may differ among different version of editscript, for we may tweak the algo sometimes

it is unpredictable which one it will use, for the slight change in data may lead it to a different path

I have noticed that if I increase the number of keys in the items above, say {:a 2 :c 3 :d 4 :e 5... the algo becomes less and less likely to detect a deletion

yeah I think I noticed the same, thank you for confirming

the human eys’s sense of the size is not the same as the algo’s. The algo count size by number of nodes, so [] is a node itself, it counts

the original editscript many version ago count the size more like human, but i find that not our use case

right, I think that's throwing me off, if I had a set maybe the deletion detection would be more consistent?

basically I need a way to detect a deletion no matter the input size

editscript is not for human looking at the diff, it’s for machines, so it should be more like memory consumption

yeah, the issue is not in me reading the edit script, it is more to consistently detect deletions

we can make the op size count configable, so one can tweak it to their liking

for example, if you prefer delete, make the cost of replacement high, delete low

etc.

please file an issue, so i can get to it sometime

the algo is driven by these cost scores, and it should be configurable

right now, they are fixed

with a huge cost of :r, you can effectively disable it

ok sounds good, I will open one

thanks

I think it would make sense to configure it /cc @U03219RPYTS @U01PAJR4N69 (my colleagues)

another option is to take out :r in config, so it is not even considered

is it currently configurable?

not right now, but we can add both options

ok sounds good, thank you for your help - will open an issue to track this

good. thanks.