ietf-mta-filters
[Top] [All Lists]

Re: Invalid syntax to cause runtime error in encoded-character

2006-11-15 16:54:21

On Fri, Nov 10, 2006 at 11:02:40AM +0100, Michael Haardt wrote:

I think we are looking at ${hex} from two perspectives: I think of a
function of (in absence of other extensions constant) arguments, and
you think of it purely as quoting.  In case we don't find a unification
we are all happy with, I suggest to find a new name that does not look
like a function at all.  Like ${0xdeadbeef}, or ${\xdeadbeef} and
${\u0040}, or just anything that not being an identifier.

I think that that difference in perspective is apparent.  Some want to
think of ${fn:} as invoking a run-time string function, If you have that
perspective, it seems to me that it's almost inevitable that one day you
will want nested evaluation of functions and variables (probably in an
order dictated by the nesting usage and not by arbitrary rules).  I
thought that the ${xx:} syntax was presented as a function reference,
allowing for further functions in the future.  So I guess I agree with
Michael Haardt here.

Imagine, for example, that :lower/:upper et al had never been thought of
for the variables draft (along with the pesky priority table).  One
might come up instead with, e.g., "${upperfirst: ${lower: ${var}}}"

That is perfectly byte-compilable..  you should be able to byte-compile
nested and mixed references anyway, as long as you don't allow for the
expansions to produce new references.  There's a difference between
nested/mixed evaluation, which I think has merit, and rescanning for new
substitutions, which if done implicitly (without an 'eval' sort of
function) could bring on a bunch of evils.

There was also this:

On Wed, Nov 08, 2006 at 04:08:33PM -0800, Philip Guenther wrote:
   ...
Hmm, I thought it was settled that encoded-characters were to always be 
expanded before variables, such that encoded-characters could be 
implemented purely in an implementation's lexer, or even via 
pre-substitution.

If you implement this in the lexer, you are allowing a 'require'
statement to change the output of the lexer: not to mention having to
have the lexer work differently for "require" strings than for others
(assuming that the prohibition against expanding strings in "require"
still stands).  I suppose one could do that, but it doesn't seem
very, well, pure.

[I've been buried in other stuff for a while, but I did spend time
during the last couple of days to read every saved list message that
came in over that period.  I think.]

-mm-