Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > Strictly speaking, only first-class functions are required, and > tail-recursion optimisation is only an implentation detail. Now it's > obvious that when it comes to real-life-size programs, this is a > *very* important detail !-)
I don't buy this. One of my favorite quotes about specifications (http://www.sgi.com/tech/stl/drdobbs-interview.html): Let's take an example. Consider an abstract data type stack. It's not enough to have Push and Pop connected with the axiom wherein you push something onto the stack and after you pop the stack you get the same thing back. It is of paramount importance that pushing the stack is a constant time operation regardless of the size of the stack. If I implement the stack so that every time I push it becomes slower and slower, no one will want to use this stack. We need to separate the implementation from the interface but not at the cost of totally ignoring complexity. Complexity has to be and is a part of the unwritten contract between the module and its user. The reason for introducing the notion of abstract data types was to allow interchangeable software modules. You cannot have interchangeable modules unless these modules share similar complexity behavior. If I replace one module with another module with the same functional behavior but with different complexity tradeoffs, the user of this code will be unpleasantly surprised. I could tell him anything I like about data abstraction, and he still would not want to use the code. Complexity assertions have to be part of the interface. -- http://mail.python.org/mailman/listinfo/python-list
