Have you considered restricting yourself initially to just first-order contract and only a fixed set of basic predicates and predicate combiners?
— boolean?
— integer?
— ..
— [listof string?]
— ..
— [vectorof real?]
— …
— procedure?
— .. recursivon ...
plus a form for attaching contracts to functions as they get exported?
(0) it’s quick to build
(1) you know the cost and it’s quite apparent to any GUIX developer [still non-trivial]
(2) you can separate the contract-checking from the main functionality, making both clear and readable in MOST cases
(3) you get systematically formed error messages
(4) you get first-order blame
Side effects:
(1) it’s simple and easy to understand
(2) you avoid the allocation cost of wrappers for HO objects and blame info
(3) you avoid the cost of repeatedly wrapping (can be bad if you use plain OO style)
(4) you avoid the compiler cost of calling through wrappers
And best of all this is compatible with future extension for ho contracts.
;; - - -
I will also say that as much as I like ho contracts and use them extensively,
making everything a function is bad for any future optimization.
Michael B. Cameron M and I are thinking of designing a hosted contract DSL on top,
via Michael’s special-purpose expanders, and experimenting with a classical optimizer,
perhaps even using Leif’s nano-passes (adapted for syntax of course).