Re: [Sbcl-devel] Re: Bug: fill and replace incorrectly ignore fill pointer

[Christophe R. <cs...@ca...>]

On Sun, Jan 05, 2003 at 09:35:20AM -0600, William Harold Newman wrote:
> > Would anyone care to come up with a policy on this issue?  I argue that
> > we do not have to signal an error, though it would be nice; on the other
> > hand nailing every case is likely to be a fair bit of work.  Is the
> > (SAFETY 3) criterion a sensible one for this, or should we query DEBUG
> > as well?
> 
> I'm skeptical about querying DEBUG here. I'm not sure DEBUG is
> supposed to have anything to do with stopping incorrect code from
> executing, my understand is that it's more about helping you
> understand the state of your program at any moment. If we could leave
> DEBUG and SPEED (relatively) orthogonal here, I think that'd be a
> (minor) feature, not a bug.

I think that's right -- DEBUG is about "how much work should the
compiler do to make this code debuggable".

> Everything else here sounds reasonable to me. I didn't go back and
> review the spec or anything, but at least it matches my recollection.

OK.

Attached is a patch that amends the "interpreter" (or "full call")
versions of seq.lisp functions to check the bounding indices.  Things to
note:
  * various FIXMEs, indicating that this is only a rough cut;
  * definite goodness in removing the END-TOO-LARGE-ERROR, replacing it
    with BOUNDING-INDICES-BAD-ERROR;
  * a certain amount of heroics in SUBSEQ on LIST arguments not to
    traverse the list twice to discover whether the bounding indices are
    OK or not -- these heroics are not performed in any other case;
  * the compiler side of things has not been touched at all yet.

This fixes the full call versions of:
  FILL, REPLACE, DELETE, DELETE-IF, DELETE-IF-NOT, REMOVE, REMOVE-IF,
  REMOVE-IF-NOT, SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT,
  NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT, MISMATCH and SEARCH
which leaves
  COUNT, COUNT-IF, COUNT-IF-NOT (probably trivially doable)
  FIND, FIND-IF, FIND-IF-NOT, POSITION, POSITION-IF, POSITION-IF-NOT
    (have compiler transforms)
  PARSE-INTEGER, PARSE-NAMESTRING, REDUCE, REMOVE-DUPLICATES,
  DELETE-DUPLICATES, WRITE-STRING, WRITE-LINE, WITH-INPUT-FROM-STRING
    (different mechanism called for, probably)
  STRING-UPCASE, STRING-DOWNCASE, STRING-CAPITALIZE, NSTRING-UPCASE,
  NSTRING-DOWNCASE, NSTRING-CAPITALIZE STRING=, STRING/=, STRING<,
  STRING>, STRING<=, STRING>=, STRING-EQUAL, STRING-NOT-EQUAL,
  STRING-LESSP, STRING-GREATERP, STRING-NOT-GREATERP, STRING-NOT-LESSP
    (same mechanism but different details [argument names slightly
    different], and have compiler transforms).

This is a fair amount of work, clearly.  On the other hand, the
*SEQUENCE-KEYWORD-INFO* trick could also be used to impose a consistent
:TEST/:TEST-NOT policy over these sequence functions, so it's probably
worth doing right...

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)