[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Substring indices everywhere? and the XS>< form
There are two major differences between 'substring' and the proposed
XS>< _notation_. For one thing, 'substring' function's interface is
written in stone: (substring str i j). All three arguments are
required, furthermore, (<= 0 i j (string-length str)) must be #t. XS><
is not bound by this interface; it can accept fewer arguments and
For another thing, substring is codified to be a procedure whose
result is a first-class value. No such promises have been made about
the XS>< notation.
One can envision the following three implementations:
(define (XS>< str i . j-opt)
(if (negative? i) (+ i (string-length str)) i)
with substring and string->number as defined in R5RS.
the same as system A but with substring/shared
((string->number (XS>< arg ...))
(substring->number arg ...))
((string->number arg ...) (r5rs-string->number arg ...))))
(this is just the outline. A Scheme compiler may notice the XS><
notation and perform the above conversion without actually requiring
string->number be a syntax. string->number may remain a normal
Any of these three systems permit an expression
(string->number (XS>< "$12345.99" 1))
which would return exactly the same result. The user thus does not
care what XS>< really is. A particular Scheme system is therefore free
to implement XS>< in any way it thinks fit -- with inlining, shared
substrings, lazy substrings, etc. User's code however remains
portable across the three implementations.
Again, the code with XS>< notation can be easily moved to a system
that implements XS>< via shared substrings. This IMHO addresses the
following Tom Lord's concern:
> This makes it awkward to incorporate the code such programmers write
> into systems which support shared substrings.
The XS>< notation also effectively removes substring indices from all
string library procedures. Again this addresses Tom Lord's and other
Furthermore, as XS>< notation is not guaranteed to be useful outside
string functions, implementing it through shared substrings appears
safer (for example, an implementation does not have to add code to do
a copy-on-write when a parent string is modified). Hence XS>< may be
implemented via a lighter version of substring/shared.
The purpose of the XS>< notation is to raise the level of abstraction,
by introducing a _notational_ indirection. The hope is to guarantee
portability of user code and to impose as few restraints on
implementations as possible. The decision as to whether a SRFI-13-
compliant system should support shared substrings is IMHO best left to
implementors. BTW, I too consider the 'XS><' name to be ugly, but I
couldn't think up anything cuter.