[Openmcl-devel] "potential numbers" as symbol names
dankna at accela.net
Wed Apr 20 19:43:53 UTC 2005
At first I thought that this was perfectly well-defined. Remember
a token is a "textual representation" (glossary), not an actual symbol
number. Section 2.3.4 seems to say that a token is not a potential
if it contains a package marker, which means that the rules for handling
potential numbers don't apply to things such as :3. However, section
2.3.4 defers to section 2.3.5 as to what is a token to begin with, and
the interpretation of 2.3.5 that causes trouble for us.
2.3.5 is somewhat ambiguous; it seems to say that :3 is a "valid
for a token", since it's listed in the table titled "valid patterns",
but that the
interpretation of that pattern is undefined. If so, this is directly
with 2.3.4, which does define its interpretation. However, if :3 is
token at all, there is no conflict, because 2.3.4 describes rules for
interpretation of tokens.
If :3 were considered a token, it would be a symbol. It is not a
potential number as defined by 22.214.171.124 (clause 1), because it contains
a character which is not a digit, number marker, etc (section 126.96.36.199,
I was confused by clause 3 of 188.8.131.52. It starts by unambiguously
defining the result of having a package marker (which is redundant,
the prior clauses already define the same result), then states that that
result is not well-defined. Then I realized that clause 3 comes into
with non-base characters which are both package markers and number
markers, not that there are likely to be any such. See section 184.108.40.206
Another minor point: It's incorrect to say that "\3" is a legit
"3" is not. Both are valid as symbol names in the sense that you can
INTERN on those strings directly (and they are two different symbols).
The question is only whether :3 and package:3 are tokens which are to
interpreted as symbols.
So we're left with two interpretations. Either :3 is a token and a
with cautionary wording in a couple places that it really isn't, or it's
undefined whether :3 is a token at all.
Now that I've worked all that out, I guess I don't much care either
It comes down to whether it's better to tolerate marginal behaviour, or
"soundly trounce" it. Giving an error is probably better, assuming
no significant performance penalty. I would think that the tokenizer
tight inner loop, so we should look at performance before deciding.
Links for convenience:
"220.127.116.11 Constituent Traits"
"18.104.22.168 Potential Numbers as Tokens"
"2.3.4 Symbols as Tokens"
"2.3.5 Valid Patterns for Tokens"
"Issue COLON-NUMBER Writeup"
-- Dan Knapp
More information about the Openmcl-devel