Fork me on GitHub
#clojure-dev
<
2018-01-29
>
martinklepsch18:01:09

via #clojure, when specifying a post condition like this, it will never throw:

{:post [nil?]}
would a patch that warns or allows this be welcome?

noisesmith18:01:36

@martinklepsch that's not how post conditions work

user=> (defn foo [x] {:post [number?]} x)
#'user/foo
user=> (foo 'a)
a
user=> (defn foo [x] {:post [(number? %)]} x)
#'user/foo
user=> (foo 'a)

AssertionError Assert failed: (number? %)  user/foo (form-init8679983479575350905.clj:1)

noisesmith18:01:51

use (nil? %)

martinklepsch18:01:29

I’m aware that this is not how they currently work, I’m arguing that the (nil? %) syntax is… confusing?

noisesmith18:01:58

so you're saying you want to replace the post condition syntax with a new one

martinklepsch18:01:20

It seems way too easy to write post conditions in a way that will never actually check anything

noisesmith18:01:53

perhaps a spec that throws if the post condition isn't a form containing %

martinklepsch18:01:00

I’m ok with whatever solution makes this more user friendly, a warning or making my above syntax work

martinklepsch18:01:09

… or something else entirely

martinklepsch18:01:59

Have to say that I do like {:post [nil?]} though. Not sure why the % was necessary in the first place?

noisesmith18:01:03

I bet there's a lot of broken post conditions out there that would break as soon as they are used as intended haha

noisesmith18:01:39

I think the idea is that you avoid creating an anonymous function just for one code path? not sure though

andy.fingerhut18:01:03

As just mentioned in #clojure Eastwood linter can detect many of these

martinklepsch18:01:33

… which is great but a large portion of people using/starting with Clojure might not start with Eastwood

andy.fingerhut18:01:47

And yes, when I first implemented it, I did find several incorrect pre/postconditions in open source Clojure projects I tested on.

andy.fingerhut18:01:10

If my implementing in Eastwood becomes the primary reason that core developers choose not to implement additional warnings/checks in core for this, then my apologies. I suspect that won't be the reason, though.

noisesmith18:01:46

this mistake reminds me of the classic newb mistake ('or x y) which just happens to return the right thing for many test cases

martinklepsch18:01:56

Yeah, didn’t mean to imply that if it came across like that 🙂 Just noticed that this will be pretty confusing for newbies. Even I look up fogus’ article basically every time I want to use pre/post conditions 🙈

andy.fingerhut18:01:12

The Eastwood docs are hopefully pretty clear on why they give warnings, and what you might be doing wrong, with advice on how to do things correctly in some cases.

andy.fingerhut18:01:03

No worries. I also didn't mean to imply that core developers will not do something like this. I don't know off the top of my head whether the condition to give a warning here is prone to false positives, but false positives in compiler warnings tend to turn into bug reports/enhancement requests.

ghadi18:01:05

2c: investing effort in pre/post conditions is probably low priority given superior capability from spec.

andy.fingerhut23:01:21

In his REPL-driven development talk, Stuart Halloway said the following: "Projects and files, and the namespace to file name convention and all of that stuff. All of that is a convention that is not necessary at all, and it is important to keep that in mind." Here is the context in case it is relevant: https://github.com/jafingerhut/jafingerhut.github.com/blob/master/transcripts/2017-jun-stuart-halloway-repl-driven-development.txt#L256-L259

andy.fingerhut23:01:28

Excellent and interesting talk, by the way.

andy.fingerhut23:01:56

However, that statement confused me. clojure.core/require enshrines this 'convention', doesn't it?