[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: contractual programming

I just read this posting, and I'd like to revise what I think doing this
_right_ would require.

/// Perhaps a good compromise would be to turn contract checking off in a
/// block of code?  Like many LISP nuts, I'm not a big fan of set!/setq,
/// and think that object interfaces should be as impervious as possible to
/// the deliterious effects of modifying existing structures, ...but set!
/// has its place, as does setter in escaping the limitations of functional
/// programming.  Perhaps a 'mute' or 'alter' form would be in order?
/// 	(mute my-object
/// 		slot1: new-slot1
/// 		slot2: new-slot2)

This form, as given, is not sufficiently general.  If functions return
multiple values, they may be hard to use (without bind).  Perhaps giving
mute more the form of 'bind' where multiple values can be accepted would
fix this.

More generic yet might be to make mute evaluate the forms it contains and
return the object muted...

/// Given this, I could be quite satisfied if contract checking were only
/// done after calls to make, mute, or when explicitly requested by the
/// programmer.  This would only leave the [god-awful] task of figuring out
/// how to conditionally compile this code.  It might even (in a static
/// program) be possible to pay for contract checking only when one uses
/// it.

Actually, even if the compiler/interpretter had only all or nothing as choices
for contract-checking, I don't think I'd mind.  It would force me not to use
contracts in such a way as to have to include any of them in a final product...

It's darn handy to be able to turn tracing/checking on and off on a class by
class or method by method basis, especially if some of the contracts are
expensive -- this way they are still there and can be used when you want them,
but your program won't just _crawl_ along _all_ the time.

Also, adding a 'mute' command won't do for all the stuff I'd want.  I'd also
want domain-contract: and range-contract: to be added as optional keyed
parameters to method, define-method, _and_ define-generic-function (where it
can be _really_ important, since enforcing the protocol of the function to
other programmers may save lots of time later by simply not kludging the code
in the first place)

	-- Scot