Comments in line
On 09/16/2014 06:13 PM, Francis Avila wrote:
> There was considerable ticket activity on the closely related issue of the readable forms for keywords (which also has some blurry edges):
> (These link to other related tickets, open and closed.)
> The clojure reader and edn specifications are also compared meticulously here:
> The http://clojure.org/reader
page is very old, unclear, and doesn't describe the current clojure reader it seems. It should probably be updated or removed considering the amount of confusion it causes.
> What I really wish for is a formal BNF of the reader and edn forms (maybe BNF of edn, then extensions for Clojure readers as needed to guarantee edn forms are always a strict subset of readable Clojure forms). The implementations of Clojure and of alternate serializations of Clojure datastructures are multiplying and not having a very precise spec is a hassle.
Writing a monolithic (E)BNF grammar for Clojure turns out to be a bit
tricky because whitespace may or may not be a token depending on context
(it is in strings, patterns, not elsewhere, some implicit meaning as a
token terminator). You really wind up with a set of tokens and then a
token based grammar (which is totally fine and well suited to
traditional parser designs) unless you want to handle
whitespace/comments anywhere as syntactic elements (which the .net
languages do) which gets messy and error prone quickly.
The argument for doing this, and the reason that the .net platform
chooses to parse whitespace and comments is that it's convenient for
enabling documentation tools, and it allows refactoring engines to
preserve syntactically "linked" comments and indentation when moving
blocks rather than discarding them. One example of this in Clojure is
marginalia  which maintains its own custom reader and has an open
issue for hacking said reader to support ClojureScript forms.
> On Tuesday, September 16, 2014 1:40:32 PM UTC-5, Bendlas wrote:
>> There are several clojure/edn readers
>> - Clojure's builtin reader
>> - clojure.tools.reader (now also the reader of cljs)
>> - clojure.edn
>> Even though EDN is a subset of clojure, I think it's easy to agree that there should be no difference in symbol/keyword syntax.
Yep which I think is a strong argument for having a clear formal grammar
that all implementations can be held to. Even if it changes in the
future it makes life easier for everyone concerned.
>> That said, clojure's reader, aswell as clojure.edn allow symbols like foo/bar/baz. clojure.tools.reader only allows foo//
>> All the readers allow symbols like foo', but fail to mention ' as a possible constituent character in their docs.
and it's language on / is quite ambigous.
seems to support the implementation of clojure.tools.reader (only foo// allowed), however clojure.edn happily reads foo/bar/baz
>> I hope to get to official consensus regarding this issue, hopefully leading to tickets and doc fixes.
>> kind regards
>> There has been persistent confusion on whether runtime-constructed, unreadable symbols like (symbol "foo bar") are considered valid, and I'd like to take this opportunity to propose, that they indeed are to be continually supported by clojure runtimes.
>> Maybe the printer should recognize them as unreadable and print them as #<symbol "foo bar"> or even #symbol ["foo bar"]
If those forms are going to be readable, using the reader macro notation
is a nice way to do it. Note however that as this would be a "standard"
reader macro like #uuid or #inst, #symbol need not take a vector and can
just have a bare string.
This would also be nice in terms of feature expressions, since it would
clearly solve the "Reading unreadable things" issue(s) mentioned on the
design page. 
Furthermore formalizing the reader grammar would help with creating new
Clojure-like "dialects"/targets (oxcart, rhyne  and others) and
ensure a minimum of readability between different platforms that doesn't
currently exist. I'm a fan of this.