From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-11-16 21:21:44
At 12:41 PM 11/14/2001, Matt Austern wrote:
>Bill Seymour wrote:
>> Beman wrote:
>> > The only real technical issue I can remember being mentioned
>> > was a question as to why the design had chosen eager rather
>> > than lazy evaluation.
>> I don't remember that one; but maybe I was taking a biology
>> break at the time. 8-)
>> Regardless of the rationale for eager evaluation (IIRC, to
>> avoid overflow as much as possible), should that really be
>> an issue? It seems like a QoI issue that wouldn't go into
>> the Standard anyway.
>Not necessarily. Consider, for example, the difference
>between list<> and vector<>. There are a few syntactic
>differences (you can write v.begin() + 5, and you can't
>do it with l.begin()), but those are minor, and could
>easily have been eliminated. The real differences are
>in the complexity of operations. The difference between
>an O(1) and O(N) operation is so important that it's
>effectively part of the interface.
>Andrei Alexandrescu argued that the difference between
>eager and lazy evaluation was something similar. He did
>not argue that one was better than the other; he argued
>that for some applications lazy evaluation made no sense
>and that for other applications eager evaluation made no
>sense, that a rational number package must document which
>strategy it uses, and perhaps that the strategy should be
Yes, and I agree with Andrei that the choice should be specified rather
than left up to the implementor. But as for making the choice
user-selectable (via policy class or whatever), I'm inclined to favor
simplicity (that is, settle on eager evaluation and be done with it) since
I view rational numbers as nice for the standard, but not something we want
to overburden with any extra complexity.
My feeling is C++ should move toward a much broader library, but in domains
less-than-central to the bulk of library users, we need to be very
concerned about complexity. My guess is that the LWG will be willing to
include the current Boost Rational Number library, but that is about the
complexity limit for a rational number offering.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk