Bad test?

[Stephen J. Turnbull]

>>>>> "Jerry" == Jerry James <james at xemacs.org> writes:

    Jerry> I'm sure it's not, in general at least.

Is that a challenge?  Too bad, I have better things to do, but it
sounds like fun.

    Jerry> What I had in mind is something like this:

    Jerry> (defmacro Assert (assertion &optional failing-case)

Obvious, correct, and useful---but mostly will involve locking barn
doors after the cow elopes with the boar.  :-(

Let's do it and document it, though.

    Jerry> In short, there is no technical reason why (- (random)
    Jerry> (random)) is better than just plain (random).

Bzzt:

>>>>> "Jerry" == Jerry James <james at xemacs.org> writes:

    Jerry> Shoot; (random) chooses one fixnum with equal probability,
    Jerry> and (random N) chooses a number from 0 to N-1 with equal
    Jerry> probability.  That's too bad; I'd like to be able to say
    Jerry> something like

    Jerry> (random (1+ most-negative-fixnum) (1-
    Jerry> most-positive-fixnum))

    Jerry> and have it give me a number in that range.

Tee hee!  Of course getting uniform over that range is hard, but isn't
that exactly the point of the subtraction?

    >> I need to change the internals documentation on regression
    >> testing, which currently recommends use of `eq' (then you get
    >> an Assert failure, and know what broke, where otherwise you get
    >> a "misc unexpected failure"), to recommend eql.  (This is not
    >> provable, it's a heuristic for many functions which return
    >> position-or-nil, the Assert failure is more informative in
    >> those cases.)

    Jerry> I don't understand.  Would my suggested change to Assert
    Jerry> help at all?

I don't know, it's heuristic.  The problem is that something like

(mapcar (lambda (x) (Assert (= (match-string "the" (car x)) (cdr x))))
        '(("the" . 0)
          ("other" . 1)
          ("three" . 0)))    ; typo for "there"

will signal wrong-type-argument for =, implying that match-string is
badly broken when actually it just returned nil as it should.  I've
actually been bitten by this case, dumb, yes, but I don't think I
would have missed the point if I'd gotten an assertion failure instead
of an apparent "new internal error" introduced by my patch to the
regexp code.  At least that's what I thought at the time.  :-)

Based on Martin's and others' practice of using eq for this kind of
case, I'm guessing that they also found it useful to get an Assertion
failure for expected types rather than some random "other failure",
while the converse case caused less confusion.

However, this does make it obvious that we need to add the
`failing-case' data to the "other failure" arm in your suggested code.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.