[EMAIL PROTECTED] wrote: > > 4. A terminating bug is preferred to a non-terminating bug. > > This is not self-evident to me. Is this somehow > related to the design philosophy of functional > languages? I was never aware of such a preference > in conventional procedural languages (though I > could easily be wrong).
This is not a paradigm based preference. It derives from the basic fact that you can test for an incorrect result, but you can't test for non-termination. Therefore if you have to choose between making it easy to inadvertantly introduce either non-termination or a trivial logic error, you are better off chosing the trivial logic error. That preference is independent of which structured/object/functional/logic/constraint/concurrent/reactive school of programming you adhere to. > It also seems directly counter to Python's "no errors > should pass silently" dogma -- a non termination > seems more noticable than silent erroneous results. Two problems with that. One we are dealing with a bug, not an error. Two, even if we classified the bug as an error noticing non-termination requires solving the halting-problem whereas noticing an erroneous result simply requires a unit-test. The reason why you see this in FP and not in OOP is that infinite/unbounded/v.large values are trivial to define in FP and (generally) not in OOP. Consequently the potential for inadvertant non-termination simply doesn't arise in OOP. > > Hence zip is generally truncating. > > I see your point in a theoretical sense, but it still > seems to me be a pretty weak reason for making > a practical decision about what should be in Python, > particularly when the justification is being transfered > from a functional programming domain to an > object/procedural one. Is any language feature that > might result in non-termination if erroneously used, > to be banned? That doesn't seem very reasonble. Of course not --- only by making python non-turing complete could such a thing be achieved. But you have overstated the position. This isn't a matter of outlawing function that could be used to write a non-terminating prodcedure. It's about a simple API design decision. A choice between two options. It doesn't require the designer to decide that one is *right* and one *wrong*. Just that one is at least slightly better than the other; or even that one was chosen simply because either was better than neither. API design decisions are not personal vendettas against your use-case :). Andrae Muys -- http://mail.python.org/mailman/listinfo/python-list
