When iterating over an IPersistentSet, do the values always come out in the same order?
Yes
Assuming you mean a particular instance of a set
Yes — the set value is unchanged.
Thank you!
In general, any kind of iteration should happen in seq order
Where do you mean "always"? The iteration order within the same JVM process might be the same, but it might be different across JVM builds.
different JVM would mean different instance, no?
Yes. I don't know how you're using this seq order, but if you're relying on a similar order across (for example) replica sets in k8s, it could surprise you.
no, I meant a particular instance of a set, as Alex asked about above.
has the core team made a public statement yet about whether they would accept or reject patches to Clojure that are generated by an LLM?
Sean, are you saying that the ownership of LLM generated code is not with the developer (which is the default ownership of written code in absence of additional contractual stipulations)? That would have deep ramifications for all the companies using LLMs to write their platforms.
@roklenarcic I think there are probably some legal grey areas. Even tho' you "own" the generated code, licensing may still trip you up -- if, say, chunks of GPL code end up in what is generated. And copyright is also an issue in the US, since copyright only protects works authored by humans. There have already been some test cases where folks have been denied copyright protection in a court of law for works generated entirely by AI. For the former, licensing, issue, you can in theory instruct some LLMs to not reproduce publicly available code fragments. GitHub Business allows you to disable public code inclusion -- but the free GitHub plan does not, for example. Some of this stuff has not been tested in court... yet.
I understand the “accidental copy of existing code” thing, but I was mostly talking about copyright, I didn’t know this has been denied in the past
I don't know about other countries' copyright law -- only US law, which has been tested a little in the courts.
https://clojure.org/dev/contributor_agreement#_no_generated_code <- it looks like we did get an explicit policy on this posted at some point; thanks to whoever did that!
@alexmiller since clarified (on http://clojureverse.org, I believe), that this would extend to AI-generated autocomplete as "LLM-generated code" as well, so folks who want to contribute patches need to be careful about the settings in their editor.
Given how tightly QA'd those patches are, would it matter whether the code in the patch was human- or AI-generated? (Genuine Q). And it would depend on the submitter disclosing the use of AI... (Is the Q is more about the copyright / provenance of the code, rather than the quality? Doesn't the CLA make the submitter liable should any issue arise in future?)
yes, it matters
for ethical reasons if none other
"the contributor can always lie" is not a good argument; the contributor can always lie about license compatibility or any other requirement. just because a policy isn't bulletproof against bad-faith attackers doesn't mean it's not worth having.
hm; the CLA says you agree that "to the best of your knowledge, each contribution will not violate any third party's copyrights" so I would interpret that to mean it's already prohibited to use an LLM, because that claim would be impossible to make for LLM-generated code.
but you see why clarification from the author of said document would be important?
Right, and the CLA also specifically says "each contribution that you submit is and shall be an original work of authorship and you can legally grant the rights set out in this RHCA".
but still, I'm sure you'd find LLM users who would argue with that
even tho it seems clear to me
If you generate code with an LLM, is it "an original work of authorship" and can you, as the submitter, "legally grant the rights set out in this RHCA"? I would say "no" to both. But IANAL.
I'd rather tell them to argue with Rich than argue with me
Hah, yes, and I think we know how Rich would feel about this 🙂
we don't have any public policy. of course, we have no plans to move the goalposts of what we expect from a patch or a contributor.
what about clarifications regarding ambiguity in said goalposts?
at least knowing if it's "we need to think about this more" vs "we don't think this is important" would be helpful