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 quo
Oops, part of the example lost formatting with word wrapping. Here's it
in full:
--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 sym
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
James Reeves writes:
> Where in the specification does it say that the edn reader should throw
> exceptions on errors?
Well, it doesn't. I think had this expectation of forbidden things
throwing exceptions from some forbidden things throwing exceptions, and
some not doing so.
Both ":/" and ":/a
Sean Corfield writes:
> Undefined behavior is deliberately very broad
I acknowledge the value of having undefined behaviour,
implementation-defined behaviour and unspecified behaviour in an
implementation, and I embrace that approach.
However, none of those are distinguished on the spec, which
Gregg Reynolds writes:
> I could put that to good use, even if it isn't 100% "compliant". Is it
> available?
You can find the current WIP code here:
https://git.euandreh.xyz/libedn/tree/src/core/rust
I'll announce on my website[0] once ready. Patches welcome.
Still missing:
- built-in tagged
Sean Corfield writes:
> 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...
This is a good guideline. A valid edn reader should read valid edn, and
the behaviour for "i
Andy Fingerhut writes:
> My personal guess: the authors of the EDN specification and
> implementation are content with their level of detail, and might not be
> interested in making them 100% equivalent in all ways. (This is only my
> personal guess. Realize that making specifications and imple
"Robert M. Mather" writes:
> It's bad UX for the canonical reader to silently accept something that
> other impls reject, but people are more likely to blame the alt impl.
It isn't really bad UX, it is just unspecified behaviour that different
implementations interpret differently. And if people
Matching Socks writes:
> This is not either/or.
Sure, I agree. When I said "I don't see a way around this type of job",
I was responding to an earlier message that said that building an
specification and an implementation that matched such specification a
very tiresome one.
My point was that wo
AFAICT, the spec-alpha2 repository [0] is the latest thing there is.
[0]: https://github.com/clojure/spec-alpha2
--
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 me
11 matches
Mail list logo