Clojure is a young language, and I believe there is little argument that some 
of the interfaces/implementations and associated docs could be improved. You 
can find plenty of examples where functions would throw exceptions for invalid 
input, others return nil in that case, and a number return garbage for garbage. 
Some of this perceived inconsistency could be improved upon, either by 
changing/adding validation code or by adding clarifications to the 
documentation of the functions. 

The symbol function doc consists of only: "Returns a Symbol with the given 
namespace and name." Unless you suggest that we all look at the symbol code 
itself before we start using those parameters, it may help to add a little bit 
more text to guide the novice user of the interface such that one knows that 
this particular function doesn't throw exceptions or return nil, but returns 
invalid output for invalid input…  for that suggestion I'm rewarded with a 
condescending "…WTF…" gender-neutral (?) rant - guess you're truly encouraging 
people on this list to ask questions and suggest solutions/improvements ;-).

My suggestion still stands: add more text to the doc-string of some of the 
functions such that the user has a better understanding of what to expect: no 
validation, nil, exception, expected parameter type, ???. I'd be happy to 
suggest wording.

Another option that may help us to use valid identifiers in our code is to have 
a function like: (clojure.core/valid-name? a-str), which is maintained by core 
(and not by us all writing some regex based on the current specs on a web 
page). We can use it in our code and tests to ensure we're following the 
current specs. If the valid characters are extended in the next clojure 
version, so is the function, and we can automatically conform. I'd be happy to 
provide code.

"Sincerely", FrankS.



On Mar 7, 2012, at 2:00 PM, Meikel Brandmeyer wrote:

> Hi,
> 
> Am 07.03.2012 um 01:11 schrieb Leif:
> 
>> Unfortunately, the reader does not actually follow this spec, e.g. it will 
>> happily accept :div#id.cla$$ as a valid keyword.  Some web programming 
>> clojure[script] libraries use this pseudo-CSS syntax in keywords, so if the 
>> reader was changed to strictly follow these rules, a lot of web code would 
>> probably break. 
> 
> It's the other way around: the reader *does* follow the spec. Feed it a valid 
> sequence of characters and you will get a valid keyword. Feed it an invalid 
> sequence of characters and you will get an invalid keyword. This is not in 
> conflict with the spec. A bad decision to do so instead of bailing out? 
> Maybe. Maybe not.
> 
> However documenting everywhere that feeding garbage in might result in shit 
> coming out has this “things in the mirror might be closer than they appear” 
> taste. WTF? The mirror is not the problem. Nor is the car manufacturer to be 
> held responsible. If the driver of a car causes an accident, it's her fault. 
> *She* is responsible. No one else.
> 
> The developers of said libraries obviously didn't live up to their 
> responsibility. Either they did not research how the reader works and what 
> valid keyword characters are. Then they did not do their job correctly. Or 
> they knew how the reader works but knowingly decided to operate it outside 
> defined limits. Then they basically gambled that things keep working and that 
> the characters will be eventually allowed in future versions of the reader.
> 
> In this particular case I would expect the bet to pay off. But if suddenly 
> the reader is changed to handle # differently, then all these libraries will 
> break. And now guess who is responsible. The reader? No.
> 
> Don't pass the buck.
> 
> Sincerely
> Meikel
> 
> PS: I hope Clojure's development mode is not switched to “fait accompli 
> driven.”
> 
> -- 
> 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

Reply via email to