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
"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
In idealized algorithmic terms, is there an efficiency justification for
distinguishing the ':/' and ':/something' cases as the reader does?
Seems like an artifact of the implementation rather than a time or space
optimization. Maybe that error is only recognized upon entering the
sub-parser for
This is not either/or.
There is room for an alternative, spec-enforcing, EDN reader.
A drop-in replacement, as it were, for those inclined to try it.
If you want speed, you use Transit anyway, right?
P.S. Even better if the alternative, compliant, reader were compatibly
licensed, to replace
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
Here is some possibly relevant information.
I suspect the reason that `(clojure.edn/read-string ":a:")` gives an error
is that Clojure's EDN reader implementation was originally developed as an
adaptation from Clojure's reader, and `(read-string ":a:")` also gives an
error. The reference
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
On Thu, Oct 22, 2020 at 12:00 PM EuAndreh wrote:
> 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
>
> Awesome, thanks!
--
You
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
On Fri, Oct 16, 2020 at 8:07 PM 'EuAndreh' via Clojure <
clojure@googlegroups.com> wrote:
>
> Hello there.
>
> I was working on implementing a specification compliant edn reader on
> Rust
I could put that to good use, even if it isn't 100% "compliant". Is it
available?
Thanks
Gregg
--
You
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
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
On Wednesday, 21 October 2020 at 00:42:32 UTC+1 EuAndreh wrote:
> But that doesn't apply to clojure.edn: it is code for a format with an
> specification, and it goes against the specification.
>
Where in the specification does it say that the edn reader should throw
exceptions on errors?
--
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
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
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
not only does clojure.edn accept invalid input, but the clojure reader
also accepts invalid input for the same reason (prioritizing speed of
implementation over validation)
user=> (name 'a/b/c)
"b/c"
On Sat, Oct 17, 2020 at 5:14 PM William la Forge wrote:
>
> My understanding is that run-time
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:
18 matches
Mail list logo
