athos log

[athos0220]

A public service announcement regarding static field interop... This is something we've run into while working on 1.12. The syntax for getting the value of a static field via interop is Classname/field - this has always been the only published syntax (other than the . special form). It seems that in the wild it is not uncommon to also see this parenthesized syntax: (Classname/field) but this has never been correct. It does "work" in returning the value of the field, but this is merely an artifact of the . rewriting in the macroexpander and was never intended. For correct expression substitution, that code should take the value of the field, and then invoke it. We are still deciding what to do about this (it is in the way of other things we are doing), but regardless I'll issue a plea to Clojure developers here to always use Classname/field without parens to get a static field value!

[athos0220]

Virtual threads are likely to have us rethink a lot of things about core.async and we've already been talking about it. After Clojure 1.12 is out I think it's likely to be high on our list. Very TBD what this will mean from a release perspective (considering the Java 21 requirement).

[athos0220]

It means “setting” and is kind of a catch all.

[athos0220]

There are a couple of things here. One, as mentioned, is that some kinds of validation have performance implications which creates tradeoffs. In general, we prefer to optimize for correct programs rather than incorrect ones - in other words, we will not penalize all correct programs with the cost of validation. (Importantly, this does not rule out validation approaches that occur at compile time, or that can be turned off with minimal penalty, or that are external.) And two is about undefined behavior being a place where evolution can occur. (We strongly reject "garbage in garbage out" as a framing in this regard.) In general, Clojure core functions define behavior for certain input sets and leave undefined what happens for other inputs. There have been many cases where those undefined input sets later became defined and behavior has been extended - either by adding arities or by new behavior on new inputs. Undefined behavior is room to grow. Prohibited behavior creates expectations that may not be true in the future - you should not rely on the rejection of input when that input may actually have meaning later. This is an important philosophical approach to design that incorporates growth.

[athos0220]

here in slack, #clojure-dev is a channel for dev of Clojure itself, so best place for this thread we're in (no sense changing now, just fyi)

would prefer to start anything like this in ask.clojure.org (where you can possibly find prior open requests and vote and/or add to them)

we are willing to consider adding things (see update-keys, update-vals in 1.11 as good examples). information to make a case: a) is this in keeping with clojure philosophy in terms of genericity, polymorphism etc b) what are the workarounds - is it in a lib, is it hard to write or easy to write badly c) if it exists in a util lib, provide usage data to make a case for putting in core - include some grep.app links or grape searches etc d) is there some potential extra benefit from having it in core (backed by an interface with custom methods in impls) for example

[athos0220]

hanDerPeder 05:20 why isn’t namespaced vectors a thing? alexmiller 05:22 not ready to bite on that idea yet. we've talked about it off and on. (and just to stay clear with it, you mean namespaced vector syntax (neither maps nor vectors "have" a namespace)) the next logical step is - what about sets. imagining #:account#{:name} made us wretch a bit and stop taking steps :)

[athos0220]

if I could loosely cut up the world (ignoring client-side cljs stuff atm): tools - usually released as git deps, usually don't need a build libs - usually deployed as jars to clojars or released as source deps to git. may have a "simple" build.clj that makes a source jar apps - not deployed, usually have a build.clj that makes an uberjar

https://clojurians.slack.com/archives/C6QH853H8/p1626831294180000?thread_ts=1626793676.095000&cid=C6QH853H8

[athos0220]

There is a branch with lazy var loading from way back (it takes some effort to merge it due to drift over the years). That branch, especially when combined with direct loading, means many fewer vars need to be loaded at startup/load time and can reduce startup times significantly. The reason it’s not been pulled in is that the delayed var loading required a conditional check (for whether its loaded) that makes every var invocation slower. Ghadi has done some work replacing that part with dynamic guards that seems like it has both fast load and fast invocation. Maybe we’ll get back to that some day, could be a nice reduction in load/start times (25-30% maybe?). There are a few other places where dynamic stuff could help as well, but I’m not sure those are life changing. Some of the value-oriented features coming to the JVM are things that would greatly benefit Clojure as more direct translations for what we do now and those might be very useful (could make real tuple support make sense for example).

https://clojureverse.org/t/do-clojure-still-have-rooms-to-improve-at-compiler-level/7802/7

[athos0220]

borkdude15:04:38 Related to something in #beginners : Has there been any discussion around allowing (Class/staticMethod foo bar baz) if staticMethod is a Java method receiving a variable number of things at the end, instead of forcing Clojure users to create an array? borkdude15:04:34 I guess this is more difficult to support in Clojure because of the dynamic typing? (currently you can look at the type of array to choose the right method) alexmiller15:04:43 yes, fogus has been working on this alexmiller15:04:12 it's complicated of course, but going to take a run at it for 1.11 probably

https://clojurians-log.clojureverse.org/clojure/2021-04-29/1619710272.250000

[athos0220]

can you please move questions like this to ask.clojure ? concrete questions that might be bugs can more usefully be asked there where they can be tracked conversational questions are probably better asked here

https://clojurians-log.clojureverse.org/clojure/2021-03-18/1616095657.109900

[athos0220]

Actually, just the opposite, the core team wishes this new feature had been included originally to make using kwarg style functions more widely used and embraced.

https://www.reddit.com/r/Clojure/comments/m7wdbd/clojure_keyword_argument_functions_now_also/grewn9o?utm_source=share&utm_medium=web2x&context=3

[athos0220]

We’ve slowly working towards making vars effectively do this. So if you read a var quote it would resolve locally and be invokable. We now do this for serialization of vars but haven’t yet made the reader change but I have it prepped in a ticket somewhere

https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/clojure-dev/near/205586235

[athos0220]

in general, all collection operations are expected to retain metadata (not all seq operations though)

https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/clojure-dev/near/191742928

[athos0220]

I'm considering core.typed dead, but I'm reviving it in a new project called core.typed xD

https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/clojure/near/188210962

[athos0220]

#= is undoc'ed and not a public feature of Clojure, so generally no one should be using it

https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/clojure/near/186498391

[athos0220]

I usually start with half an hour of OSS as a warm up . Then switch to normal job. Then some OSS after 20:30. I work only 4 days for money, so I have 1 day + weekends to do more on OSS.

https://clojurians.slack.com/archives/C03RZGPG3/p1573679916424700?thread_ts=1573679328.419100&cid=C03RZGPG3

[athos0220]

clojure.testがコアから分離される？

clojure.specと同様に、clojure.testの開発ペースを上げるために、clojure.testのコアからの分離が検討されているらしい

https://clojurians.slack.com/archives/C06E3HYPR/p1572362665088900

https://archive.clojure.org/design-wiki/display/design/clojure.test%2Bimprovements.html