As someone who has spent a lot of time around standardization committees (eight years on ANSI X3J16 C++ and some time around the ANSI C work before that, as well as years of BSI work as well), here's how I view the EDN specification: it states what is valid or invalid, a compliant reader should parse valid input correctly, what a compliant reader does with invalid input is either not specified or it is undefined.
This is very common in standards and specifications. C and C++ have undefined behavior (where the standard places no restrictions on what the system can do -- and does not require it be documented either!), implementation-defined behavior (where the standard allows systems to do what they want but it must be documented), and unspecified behavior (where the standard provides some guidelines but otherwise does not specify what a system should do, not is it necessarily required to be documented, but it is "defined" behavior somehow, e.g., order of evaluation of arguments). Undefined behavior is deliberately very broad: a system can silently accept erroneous input with any outcome it chooses or it can dump core or launch missiles. It's generally the user's responsibility to ensure they do not provide erroneous input. In the case of Clojure's EDN implementation, it makes sense to match the Clojure reader's behavior in cases where the EDN is "not valid" (i.e., does not have a defined meaning). In other EDN implementations, it might make more sense for EDN that has an undefined meaning to be rejected. If you find valid EDN that a particular EDN reader fails to process correctly, that's a bug. If you feed it invalid EDN, well, you may or may not get an error or a value or... On Tue, Oct 20, 2020 at 4:42 PM 'EuAndreh' via Clojure < clojure@googlegroups.com> wrote: > The speed over validation is only valid for Clojure's LispReader, not to > clojure.edn. I'm completely fine with Clojure's reader keeping all of > those weird behaviours, and many other more. > > But that doesn't apply to clojure.edn: it is code for a format with an > specification, and it goes against the specification. Having it be > faster or slower is less relevant in face of it not being correct, where > correct means "matches the specification". > > -- > 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/87362bel34.fsf%40euandre.org. > -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- https://corfield.org/ World Singles Networks, LLC. -- https://worldsinglesnetworks.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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/CAD4thx83wK_UcVv_jq7aGqiLFzRwi0PR0J-_M3Pf5eNzerSDPw%40mail.gmail.com.
