Thanks for the explanation - I tried to search for previous discussions and bug
reports about this issue before I posted, but it's clear I didn't look hard
enough...
I could still argue that there is a bug in the documentation that should spell
this out - especially when it has been discussed several times in the past… it
could save a lot of time, confusion and rehashing.
Maybe the keyword/symbol doc string should add something like: "Note that the
identifier-string is not checked for correctness, which implies that function
will return an invalid value for an invalid identifier.".
Personally I think it really helps if the doc-string specifies the contract,
especially when it has been decided to leave it somewhat ambigeous on purpose.
Thanks, FrankS.
PS Guess we can see the consequences of silently returning invalid values:
possibly creating legacy that depends on those, like the json examples.
On Mar 6, 2012, at 3:23 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 06.03.2012 um 21:28 schrieb Frank Siebenlist:
>
>> So… spaces are not allowed in symbol and keyword identifiers according to
>> the "spec"…
>>
>> although Stu doesn't quote the phrase following the allowed chars, which
>> reads:
>>
>> (other characters will be allowed eventually…)
>>
>> which seems to keep the door open for allowing spaces in the future (?).
>>
>> If space are not allowed, then it seems we have a bug in (keyword …) and
>> (symbol …),
>> if they will be allowed in the future, then (pr …) could/should be enhanced.
>
> I think this has been discussed several times in the past.
>
> This is *not* a bug in keyword or symbol. A string with spaces is simply not
> in the domain of these functions. So by definition it cannot be a bug. What
> happens is a pure decision by the implementer. The functions could throw an
> exception. Or they could return an invalid value. symbol and keyword do the
> latter. (Whether this is good or bad might be a matter of discussion, but it
> is not a bug.)
>
> And of course vice versa: the behaviour of symbol or keyword is *not* the
> definition of valid keywords/symbols. That is what Stu cited.
>
> I doubt that spaces will be officially allowed until there is – say – #|foo
> bar| for symbols and #:foo bar: for keywords.
>
> Until then a translation of {"Foo Bar" 35} to {:foo-bar 35} is a quite
> feasible workaround.
>
> BTW: Similarly you can use non-ASCII characters for symbols in your clojure
> code. This code would then be broken. The reader doesn't complain, but the
> “spec” says: only ASCII characters are allowed. Same situation as above.
>
> BTW2: There are a lot of things which might be desirable for various reasons.
> Spaces in symbols or keywords might be one of these things. But that doesn't
> mean it's a good idea to implement it. In Clojure's past there were several
> things which were requested with a lot of pressure (often combined with “sky
> is falling” comparisons), which were not implemented in the language. Only
> after long considerations changes went into the language (often) providing a
> superior solution to the previously requested versions. Patience is a
> required skill of a clojurian. ;)
>
> Sincerely
> Meikel
>
> --
> 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
--
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
