TRANSLATE-SEQ wasn't correctly accounting for submatches. The same bug occurred in a parallel position in TRANSLATE-CHOICE; when I fixed it there, I neglected to fix TRANSLATE-SEQ as well. Olin

This commit is contained in:
marting 1999-10-08 18:12:00 +00:00
parent f8975842de
commit de5a415580
1 changed files with 6 additions and 1 deletions

View File

@ -39,6 +39,11 @@
;;;
;;; - paren count in the returned string.
;;;
;;; [This is a newer description; is it correct?]
;;; - A vector mapping submatches (vector index 0 is submatch 1)
;;; to the paren for that submatch (the first paren is paren #1).
;;;
;;; [This is my original description.]
;;; - Vector of parens numbers used for submatching. The first paren is
;;; numbered 1. #F means a dead submatch -- one we can tell statically
;;; will never match anything.
@ -199,7 +204,7 @@
(values (string-append s1 s)
2
(+ pcount1 pcount)
(vector-append (mapv (lambda (sm) (+ sm prev-smcount))
(vector-append (mapv (lambda (p) (and p (+ p prev-pcount)))
submatches1)
submatches))))))