Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-05-09

Channels

#clojure
<
2019-05-09
>
hlolli02:05:44

would ^"[B" be the right way to typehint the java equivalent of string[] ?

hlolli02:05:30

ah forgot the semicolon in ^"[Ljava.lang.String;"

tabidots13:05:33

@hlolli how would I do that for an array of BigIntegers?

hlolli13:05:14

@tabidots make an instance of it in clojure and do .getClass interop

4
dpsutton13:05:23

(str (class (make-array String 0))) can spit that out for you i think? @hlolli

hlolli13:05:10

that works too

dpsutton13:05:35

i bet there's a way to get it without the class keyword at the beginning

hlolli13:05:28

all in all, this typehint does look very cryptic to me, but I guess the combination of arrays/types is almost too infinite for a special typehint symbol to be implemented for each and one of them?

hlolli13:05:15

well, I'll get used to it, I'd imagine all alternatives would conflict with the reader

dpsutton16:05:38

every-pred's docstring doesn't guarantee the order of evaluation, just that it will stop on the "first" one that returns a logical false value. Is it improper to do ((every-pred integer? even?) nil)? Are we guarnteed that integer? will check before even??

dpsutton16:05:07

inverting the order will throw an illegal argument exception

dpsutton16:05:51

(also says set of predicates which is why first might be ambiguous)

dpsutton18:05:56

@jimmy I see the source now allows for that. But I want to know if clojure will guarantee this going forward or if it just happens to be ordered now

Jimmy Miller18:05:09

I know you think the doc string is ambiguous, but arguments are vectors, not sets. It does say it takes the first argument and that it short circuits. Short circuiting is an ordered operation. But more than that Clojure takes backwards compatibility very seriously. Changing the order would be a huge breaking change. It will remain that way for as long as Clojure exists.

dpsutton19:05:14

I don’t believe the arg is a vector. I understand the backward comparability but I’m not sure this is considered a contract of every pred or just an implementation detail

dpsutton19:05:18

And I certainly grant this is unlikely to change.

dpsutton19:05:26

Just wondering if it can’t change

Jimmy Miller19:05:43

@dpsutton What sort of evidence are you looking for that it won't change?

dpsutton19:05:06

A docstring that the preds are applied left to right

dpsutton19:05:47

Maps are ordered up to 8 elements. But it’s not in a docstring so relying on it is crazy and it’s best ignored

dpsutton19:05:53

But also just being told it’s no big deal. Just musings on this one

Jimmy Miller19:05:42

The docstring is trying to say that. But it is just not explicit. "Note that f is short-circuiting in that it will stop execution on the first argument". I know you think this is ambiguous, but arguments to a function are ordered and that is what first is referring to here. The docstring definitely isn't going to change to remove the ambiguity. But this code hasn't changed in 8 years and won't change in the future.

dpsutton19:05:32

fair enough 🙂

noisesmith19:05:49

unordered arguments would break so many things...

Jimmy Miller19:05:13

Also test cases imply this. 

;; 2 preds, short-circuiting
   false    ((every-pred number? odd?) 1 :a)
   false    ((every-pred number? odd?) 1 3 :a)
   false    ((every-pred number? odd?) 1 3 5 :a)
   false    ((every-pred number? odd?) 1 3 5 7 :a)
   false    ((every-pred number? odd?) 1 :a 3 5 7)

deva19:05:29

Hello every one. Are there any reporting tools available in Clojure. Any body tried integrating BIRT into your clojure app ?

seancorfield20:05:17

@jimmy The docstring is clear that the returned function f will short-circuit on the "first argument" but says nothing about the order of the predicates. Just the order of arguments to f.

seancorfield20:05:03

So I'm with @dpsutton that the docstring gives no explicit guarantees about the order that f will apply the predicates (to each argument).

seancorfield20:05:46

It just says it will stop at the first argument for which not all the predicates return false. It could apply the predicates in any order.

Jimmy Miller20:05:48

@seancorfield Yes, you are right, I misread.

Jimmy Miller20:05:31

It would still be a very large breaking change. And the tests seem to expect that the preds are applied in order.

Jimmy Miller20:05:41

I don't see that happening.

seancorfield20:05:45

Aye, I agree it would be unlikely -- but it is still an implementation detail -- and the core team has changed implementations occasionally in the past that break behavior that was not guaranteed by the docstring.

dpsutton20:05:35

@seancorfield you are saying what i was thinking much more concisely and clearly 🙂

Lennart Buit20:05:11

its like a contract, what isn’t promised isn’t guaranteed 🙂

Lennart Buit20:05:40

I sometimes wish there was a bit more chaos in programming. Things that werent guaranteed randomly changing behaviour

Lennart Buit20:05:55

(only in tests!)

seancorfield20:05:35

Years ago, I worked on a C compiler system that deliberately had variable behavior for undefined and unspecified situations 🙂

Lennart Buit20:05:02

Yeah, I toyed with the idea to make a map/set impl that randomized its order

seancorfield20:05:31

It was a code checking system, so it detected these situations explicitly in the runtime and handled them -- rather than just letting things blow up or always behaving in a predictable manner 🙂

seancorfield20:05:20

The confusion stems from both every-pred and the function it returns both being variadic.

lilactown20:05:07

I expect that a change in every-pred’s order would be a breaking change though

lilactown20:05:20

there’s implicitly some order

lilactown20:05:36

the docstring just doesn’t say which one exactly

lilactown20:05:11

so I wouldn’t expect the order to change

seancorfield20:05:51

It could apply the predicates all in parallel 🙂

dpsutton20:05:59

calm down djikstra 🙂

dpsutton20:05:23

i think i remember him envisioning conds all working like that. thought it was right around the corner

lilactown20:05:15

I think that’s contra to the short circuiting. 😛

dpsutton20:05:24

@ghadi did you have thoughts? I saw you typing

ghadi20:05:56

can a man rage type into an input box and then delete it in peace? 😂

😂 16
4
dpsutton20:05:18

absolutely. but i always enjoy your thoughts

Lennart Buit20:05:21

hahah, typing notifications are so annoying

Lennart Buit20:05:57

type… think… revisit… remove

ghadi20:05:22

i was going to say that there is implied order

ghadi20:05:42

and changing order is a solution -- what's the problem?

ghadi20:05:56

can always augment the docstring

devn20:05:35

https://dev.clojure.org/jira/browse/CLJ-1872 - empty? is broken for transient collections I spent a little time staring at what it would take to submit a patch for this. Do I understand correctly that RT seqFrom and RT canSeq would need to include logic for TransientVector and company?

lilactown20:05:09

you might try #clojure-dev

devn20:05:26

I might, figured I'd throw it out here first.

lilactown20:05:31

I’m not super familiar with the RT stuff

devn20:05:53

posted it over there

noisesmith20:05:26

I feel like I've seen this pattern over and over - transient collections working for a specific use case (blindly accumulate items in one big reduce then persist), and all kinds of ops we expect for collections not working or working weirdly on transient collections

noisesmith20:05:40

the bugs get fixed eventually (I don't know if any of the collection features have been called wontfix yet), but they keep coming up

noisesmith20:05:49

or maybe my memory is skewed

noisesmith20:05:39

also iirc at best that transient coll will give you ~15% perf boost, and that's if it's in your main bottleneck

devn21:05:21

@noisesmith yes, there definitely are more than a few transient tickets