My understanding is that run-time validation is often left weak in
preference to speed of execution. In contrast to validation by the
"compiler". Thus clojure throws many more exceptions than does the edn
reader. --Bill la Forge
On Friday, October 16, 2020 at 9:07:40 PM UTC-4 EuAndreh wrote:
>
> Hello there.
>
> I was working on implementing a specification compliant edn reader on
> Rust, and I found that clojure.edn/read itself isn't specification
> compliant.
>
> I have three examples below that should all throw exceptions, but
> instead they are valid values according to clojure.edn/read. The quotes
> were taken verbatim from the text of the specification[0].
>
> --8<---------------cut here---------------start------------->8---
> ;; "Per the symbol rules above, :/ and :/anything are not legal keywords."
> [(edn/read-string ":/")
> ;; "It can be used once only in the middle of a symbol to separate
> the _prefix_ (often a namespace) from the _name
> _"
> (name (edn/read-string "a/b/c"))
>
> ;; specification doesn't talk about namespaced maps
> (edn/read-string "#:a{:k 1}")]
>
> [:/ "b/c" #:a{:k 1}]
> --8<---------------cut here---------------end--------------->8---
>
> I couldn't find many references to these issues, other than a Jira
> ticket[1] and a thread on clojure-dev[2]. Both talk about
> clojure.edn/read being consistent with LispReader, though. I have no
> opinions on that.
>
> Since the clojure.edn/read is an edn reader, shouldn't it comply with
> the edn specification? Maybe not the namespaced maps parts, which the
> specification itself could be extended to cover. But the other two cases
> are explicitly forbidden on the specification, and clojure.edn/read
> allows them.
>
> I'm willing to write a patch to fix those, but is it something that
> would be welcome? One could consider it a breaking change since the
> reader will stop accepting data that is now does, but I could also argue
> that this is a bug on the reader that was fixed, and the behaviour was
> changed to match the expected behaviour, which is the specification.
>
> The specification itself could change to match the behaviour of the
> reader, but this is not desirable since it would invalidate the work
> that others have done to implement edn outside of Clojure.
>
> The tension between breaking the reader and matching the specification
> should, IMHO, be favoured towards the matching the specification.
> Otherwise, the actual specification isn't what edn-format.org says, but
> it would instead be "whatever clojure.edn/read does", which is worse.
> The value proposition of having an specification to begin with is lost.
>
> WDYT? Is there any other resource on this that I missed?
>
> [0]:
> https://raw.githubusercontent.com/edn-format/edn/a51127aecd318096667ae0dafa25353ecb07c9c3/README.md
> [1]: https://clojure.atlassian.net/browse/CLJ-1530
> [2]: https://groups.google.com/g/clojure-dev/c/b09WvRR90Zc/discussion
>
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/clojure/1a9c0924-0b94-4094-8fa0-c8cd8f9bc667n%40googlegroups.com.
