On Tue, Mar 08, 2005 at 12:28:23PM -0500, Cyrus Daboo wrote:
Hi Rob,
--On March 8, 2005 12:02:27 PM -0500 Rob Siemborski
<rjs3(_at_)andrew(_dot_)cmu(_dot_)edu>
wrote:
While (3) is a cleaner design, introducing a dependency on variable
create the possibility that some implmentation that doesn't want
to implement variables but needs access to NUL, etc will do (1) or
(2) instead, thus defeating the goal of interoperability. If that
is a plausible risk, then (2) or (1) should be picked from the
start.
I therefore would prefer (2).
Same here.
With (2), do we even need to make the statement that an extension will
override the base spec behaviour? After all, that is what extensions
implicitly do. i.e. why can't we leave it exactly as it is now in the base
spec, and an extension written independently of that.
I think of the backslash character escapes in quoted strings as
something processed at the lexical stage. That is, a backslash sequence
inside a quoted string is an instruction to the lexer that affects the
way the quoted string is internalized. Some of the comments in this
thread have suggested that these escape sequences are handled in some
other way. I suppose that's a valid implementation decision (though I
haven't though about it much: I hadn't really considered that this was
other than a lexical function).
If you're saying that an extension can change the way these escapes are
interpreted, then you are saying that "require" can change the lexical
input process (at least for implementations that process the quoted
strings in this way). I don't think that's a good thing. The way
extensions are specified allows "require" to be processed as a
runtime directive (unless I'm all wet on that).
By the time you get to where an extension can process other backslash
sequences, the sequences have already been processed. So where the
lexer/tokenizer has already internalized "\a" as "a" -- what's an
extension to do?
With this interpretation, the only way to change the way that
single-backslash-style escapes in quoted strings are scanned is to do
the change at the base spec level. This does indeed bring up
backward-compatibility issues. One way of addressing that is to have
some kind of base-spec-version marker in the script.
Collaterally, being able to have an extension change the interpretation
of strings at run time would require some other way of embedding the
desired information, other than using a single backslash escape,
that is. Double-backslash sequences would be ugly.
Another alternative would be to have a way to set a "variable" to
a particular code sequence. Then you could include a "${var}"
reference to include that code. I don't know if this is better or
worse than a namespace extension, though..
Yours,
-mm-