Dem #Linke LV Berlin habe ich das Plakat mal ein wenig korrigiert.

Bizarr eine #Pershing2 abzubilden, die dank #INF Vertrag im Okt 88 abgezogen wurden. 

Aber kein Problem mit täglichen russischen Raketen Angriffen auf die #Ukraine oder SSC-8/9M729 in #Kaliningrad.

@poliorcetics KDL doesn’t specify number representation, so implementations are free to pick what different formats of numbers get represented at. For example, kdl-rs treats 1 as an Integer, and 1.0 as a Float, but it could just as well have, for example, bignum support. One thing 2.0 did add is the keywords #inf, #-inf, and #nan, which MAY be used to represent the IEEE 754 float special values, but it’s still up to implementations how they’ll get treated practice.

This aligns with, say, how a lot of JSON implementations handle numbers (and JSON doesn’t even have the special values!)

@unlambda the data model is exactly the same, fortunately, with the exception of v2 explicitly supporting #inf, #-inf, and #nan for floats.

Besides that, documents that parse correctly in both v1 and v2 will represent the same exact data--with the exception of multiline strings, which are both stricter in v2 (so it's less likely to have a conflict), and the fact that v2 dedents multiline strings.

So this document:

my-string "
    foo
    "

will evaluate to "\n foo\n " in v1, and "foo" in v2. I'm debating whether we should tweak the multiline syntax so this corner case isn't possible, but it seems relatively minor.

What that means is that once I finish rewriting the v1 parser for kdl-rs, you'll be able to do something basically like kdl::v2::parse(input).or_else(|_| kdl::v1::parse(input)) and it should be able to consume any KDL doc. In fact, I might make it so that's the actual FromStr implementation (and you can be more strict by invoking the parsers directly).

And since the data models are identical, all you have to do to convert from v1 to v2 is:

let mut doc = kdl::v1::parse(input)?;
doc.autoformat(); // v2 formatting by default
print!("{doc}");

@nikitonsky I was about to reply that none of those changes break the reader in unusual way when older version of clojure is used. like reader of any version of clojure prior to 1.10 will not read ##Inf as something valid, exception will be thrown. Unlike 42_000 that can be read as 42 followed by a symbol _000.

But I forgot that underscore does not stop number reading in any version of clojure. So I don't know any technical difficulties in adding separators for number literals.

@dotfox what do you mean? Multiple languages with 15+ year history make the change and it’s been fine so far? EDN is also not set in stone: they’ve added tagged literals, namespaced maps, duplicate key check, ##Inf recently. So there’re multiple precedents. It's been fine so far?

@tagesschau Nun, zum #INF Vertrag kann hier ggf. nachgelesen werden: https://www.ippnw.de/commonFiles/pdfs/Atomwaffen/factsheet_INF_A-Z.pdf --> demnach sind die #USA und #Russland mega daran interessiert gewesen, den Vertrag auslaufen zu lassen..., von daher hätte die @tagesschau hier auch mal nachlesen können

“The 2011 treaty placed ‘verifiable limits’ on the number of #IntercontinentalBallisticMissiles & #NuclearWarheads deployed by the countries.

“‘Our relations have degraded, & that’s completely & utterly the US’s fault,’ #Putin said.

“‘If the US conducts tests, then so will we,’ Putin said. ‘Nobody should have any illusions that global strategic parity can be destroyed.’ Other #nonproliferation agmnts, incl the Intermediate-Range Nuclear Forces, or #INF, treaty have fallen apart in recent yrs.