Using UBF outside of UBF, was: Using -spec for callbacks when defining behaviours

[Scott Lystig Fritchie]

Mikael Karlsson <karlsson.rm@REDACTED> wrote:

mk> Yes, I think that contract checkers that are "pluggable" at
mk> validation time is a good way to go, and if you find a standardized
mk> way or "formalized" pattern to put it in the process of Erlang code
mk> making the better. Joe Armstrongs UBF contracts is a good example. I
mk> agree that you should not rely on static checks, but on the other
mk> hand they are a good first check and especially for Erlang I think
mk> you can catch errors that you would later at run-time (Dialyzer do
mk> find errors).

For those readers who don't know what UBF is or where to find its source
code, please see the following projects at GitHub:

       http://github.com/norton/ubf
       http://github.com/norton/ubf-abnf
       http://github.com/norton/ubf-eep8
       http://github.com/norton/ubf-jsonrpc

I think it'd be cool to see a paper at this year's ACM ICFP Erlang
Workshop that tried to bridge the gap between dynamic and static typing
by, for example, putting the UBF contract checker in between calls to &
from Erlang functions (without TCP or whatever in the middle).

During my talk last week at Erlang Factory San Francisco, Joe Armstrong
asked me if we (my employer, Gemini Mobile) bothered to turn off the
contract checker in production or if we'd measured its overhead.  Gemini
hasn't bothered because it has been fast enough not to worry about(*).
If someone wants to really measure the cost and write up the results,
that'd be cool too.

-Scott

(*) Besides, the security blanket of the checker's extreme fussiness is
nice.  :-)