Hi,
The reader (LispReader) and the interning functions (symbol and keyword) are
separate. The reader tries to enforce some constraints, but overlooks some
edge cases, before eventually interning. The interning functions do not
validate input.
Besides the problems you raised, there are some confusing edge cases
involving colons. For example, there is no implicit way to produce a symbol
of the name ":b", but you can get away with the qualified form (read-string
"user/:b"). Similarly, (read-string ":user/:b") produces a keyword symbol
of the name ":b".
Also, repeating colons are disallowed, and checked in the reader.
Presumably, this is to prevent reading something like "a/::b". But then the
rule could probably be relaxed to only check for colons at the start of the
name. (Incidentally, this would be useful for applying the reader to data
-- as swank-clojure tries to -- from other lisps such as CL, where foo::bar
is meaningful.)
Meanwhile, the interning functions do not check for any of this. You can
get away with (symbol "a::b") and so on. I suspect it would take some more
serious refactoring to get them to run the same checks as the reader, but I
don't know if they are intentionally or accidentally more liberal in the
first place. Anyway, I would like to see at least the reader adopt a more
complete and consistent validation routine too.
Cheers
On Tue, Oct 19, 2010 at 11:02 AM, Rob Lachlan <robertlach...@gmail.com>wrote:
> There seems to be a discrepancy between what keyword names are
> supposed to be allowed, according to the reader documentation, and
> which the reader actually allows. For instance, periods are supposed
> to be disallowed in keyword names, and only one forward slash allowed,
> but no errors are thrown at something like this:
>
> {:f/o/o.o :bar}
>
> The key :f/o/o.o is interpreted as a keyword with namespace f/o and
> name o.o
>
> Using the keyword function, we seem to be able to make keywords out of
> any pair arbitrary strings, even including spaces. This might seem
> pathological, but since keywords just evaluate to themselves there
> doesn't seem to be great harm in allowing this kind of liberal
> behavior. (Note also that keywords don't create a namespace, so we
> don't have to worry about inadmissible namespaces for keywords.)
>
> On the other hand, if this isn't to be allowed, then shouldn't the
> keyword function throw an error when inadmissible strings are provided
> for namespaces or names? I should point out that the symbol function
> is also similarly permissive, and that seems like it might be more
> worrisome. I would be in favor of keeping the behavior of the keyword
> function as is, but possibly making the symbol function a bit
> stricter.
>
> Note, I'm using version 1.2. This all is motivated by a stackoverflow
> discussion:
> http://stackoverflow.com/questions/3951761/what-are-the-allowed-characters-in-a-clojure-keyword/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com<clojure%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
Abhishek Reddy
http://abhishek.geek.nz
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
