Nathan Lilienthal

The trick is going to be moving forward with this while maintaining functionality.

True, but I'd expect (might not be a huge deal to ensure this) `Contract A ... => B === Contract { A ... => B }` ignoring the syntax issues.

Before I spend too much time thinking about what you're doing here. I'd be very cautious of the notion of currying here. Since Ruby is not implicitly curried.

Very cool library, but I would avoid doing this here. Ruby is _not_ Haskell and contracts are perfectly well defined in both contexts. It is true that Haskell lends itself...

That's still probably one of the best options. Has anyone considered parsing our own contract language before? Is this something we are 100% opposed to?

The beauty of parsing our own language would be the ability to avoid all the namespacing and syntax restrictions. To @robnormal's point we would be smart to evaluate contracts within...

Well, and that in addition to only adding the `Contract` method, all contracts are evaluated in their own namespace. This would be exceptionally helpful for defining "types" (classes with a...

``` ruby class A # Bunch of application logic. end define_contracts do class A def valid? # ... end end end class B Contract "A => Num" # using a...

This is nice too because it would still work if users defined constants on the global namespace, however it provides a way to avoid that. Oh and, I should have...

Not necessarily. We could make it so it simply executes within a namespace of the current context with the base contracts included. That way the classes and variables where a...