defcontract-proposed.clj

(defcontractedfn1 sqr
  "Calculates the square of a number."
  ([n]
   :requires
   (number? n)
   (not (zero? n))

   :body
   (* n n)

   :ensures
   (pos? %)))

;;;;;;  OR

(defcontractedfn2 sqr
  "Calculates the square of a number."
  ([n]
   :requires
   (number? n)
   (not (zero? n))

   :ensures
   (pos? %)

   :body
   (* n n)))

;;;;;;  OR

(defcontractedfn3 sqr
  "Calculates the square of a number."
  ([n]
   :requires
   number?
   (not (zero? n))

   :ensures
   pos?

   :body
   (* n n)))


(sqr 0)
; java.lang.AssertionError: Assert failed: (not (zero? n))

(sqr 7)
;=> 49

(sqr -7)
;=> 49

Is there any reason why you would strictly enforce the ordering of the body, pre and post conditions? It should be possible to implement the macro so that the order of these is flexible, right?

I think I'd prefer option 2, if the order has to be set. Even though option 1 seems to follow a natural order of before, during, and after, I think of pre and post conditions as part of the contract, and in my mind they go together.

Why is body part of the contract? Shouldn't a contract just declare what is required and what is ensured? You give me X and I'll give you Y, we don't specify how I'll get Y from X.

@paraseba
defcontract is unfortunately a poor name for what this is... a better option is something like defcontractedfn. Sorry for the confusion.

I suppose there is no technical reason why the parts should be explicitly ordered. I think if this lib gains any widespread use (crossing fingers) then an idiomatic ordering will fall out of it. However, I'll support arbitrary ordering in any case.

@fogus I totally agree. I'm all in favour of encouraging idioms rather than enforcing them. But then I used to be a Rubyist rather than a Pythonista - so that's to be expected ;-)

How about adding other keywords that act like -> macro?:

:ensure-> pos? even?

Of course :ensure->>/:requires->> would be available too

I think I will keep the keywords as is and instead prefer that ->/->> be used explicitly. However, one thing I was playing with was allowing functions to be used directly which implicitly means that in the case of :requires the args are passed in and with :ensures the return. That way you can write something like defcontracted3.

Cool! how will you enable/disable the checks?

I'm not sure I follow.

ensure and require conditions are always checked and enforced? Can I opt out of that behavior, for instance for performance reasons in production environments?

I see what you mean. Nothing will happen if *assert* is set to false. In fact that pre and post conditions will not even be generated.