Hacker News Reader

Comment by zokier | Hacker News Reader

I don't understand the whitespace handling here, it seems very underdefined?

Taking the example from github page (abbreviated):

    first name [John]
    last name [Smith]
    address [
      street address [21 2nd Street]
    ]

why isn't it equivalent to this json?

    {
        "first name ": "John",
        "\nlast name ": "Smith",
        "\naddress ": {
            "\n  street address ": "21 2nd Street"
        }
    }

somehow the whitespace is instead implicitly magiced away, but that isn't defined in the grammar anywhere as far as I can see?

View on HN

Simple answer is that apparently the examples are false, feeding the above string to the JS parser spits out the following object:

    {
      "subjevkos": [
        {
          "prefix": "first name ",
          "jevko": {
            "subjevkos": [],
            "suffix": "John"
          }
        },
        {
          "prefix": "\nlast name ",
          "jevko": {
            "subjevkos": [],
            "suffix": "Smith"
          }
        },
        {
          "prefix": "\nis alive ",
          "jevko": {
            "subjevkos": [],
            "suffix": "true"
          }
        },
        {
          "prefix": "\nage ",
          "jevko": {
            "subjevkos": [],
            "suffix": "27"
          }
        },
        {
          "prefix": "\naddress ",
          "jevko": {
            "subjevkos": [
              {
                "prefix": "\n  street address ",
                "jevko": {
                  "subjevkos": [],
                  "suffix": "21 2nd Street"
                }
              }
            ],
            "suffix": "\n"
          }
        }
      ],
      "suffix": "",
      "opener": "[",
      "closer": "]",
      "escaper": "`"
    }

tbh seems like a pita to clean up afterwards

Thanks for taking the time to look at this. ;)

What you are getting is the plain Jevko parse tree.

The examples explicitly talk about a format built on top of that. See this answer: https://news.ycombinator.com/item?id=33334314

Good question!

Jevko itself, defined by the spec, is not the same as a format based on Jevko.

If you use a plain spec-compliant Jevko parser you for this you indeed should have all whitespace included. Although it will look more like this:

  {
    subjevkos: [
      { prefix: "first name ", jevko: { subjevkos: [Array], suffix: "John" } },
      { prefix: "\nlast name ", jevko: { subjevkos: [Array], suffix: "Smith" } },
      { prefix: "\nis alive ", jevko: { subjevkos: [Array], suffix: "true" } },
      { prefix: "\nage ", jevko: { subjevkos: [Array], suffix: "27" } },
      { prefix: "\naddress ", jevko: { subjevkos: [Array], suffix: "\n" } }
    ],
    suffix: ""
  }

Now on top of that you can build a format that specifies what happens to whitespace, etc. Usually you'd want it trimmed if the prefixes mean keys in a map.

The simplest format/library that does just that is this:

* https://github.com/jevko/easyjevko.lua

* https://github.com/jevko/easyjevko.js

That will give you the JSON (or equivalent) that you expect (with autotrimmed keys).

If the Jevko spec does not handle white space and leaves it to clients, then it will cause issues for data interchange. In order for 2 different clients to read the same Jevko file, they will need to align on how they handle white space.

This is a valid concern, but on a higher-level.

Jevko leaves whitespace handling not to clients, but to formats built on Jevko which would be the thing the clients typically use (rather than plain Jevko). Such formats of course should be clearly specified, which is something I hope to get around to soon.

I already have a good candidate format for specifying first, which has 2 implementations:

* https://github.com/jevko/easyjevko.js

* https://github.com/jevko/easyjevko.lua

For more details see also:

* https://news.ycombinator.com/item?id=33335181

* https://github.com/jevko/specifications/issues/1

For the dubious benefit of defining only three special characters (opening delimiter, closing delimiter and escaping prefix) without the usual commitment of defining a whitespace character class (like in most mainstream languages) and/or more delimiters and punctuation.

Jevko seems "simpler" than traditional syntaxes in the same way that a heap of bricks is simpler than a wall.

Without any whitespace rules I wouldn't really call this human-readable format. The canonical serialization of a tree is without any whitespace and unlike json/xml/sexpr you can not reformat the document for human readability because any added whitespace changes the content.

Plain Jevko is a notch below JSON/XML/S-expr -- it's not really a format, but a syntax that can be leveraged to build a format.

This is where the rules for whitespace would be specified. These can then be taken advantage of by tools to reformat, etc.

The simplest format that I came up with and should specify next that will most likely do what you want is Easy Jevko. For details see this rabbit hole: https://news.ycombinator.com/item?id=33337098

For an alternative minimal syntax which is based around whitespace check out:

* https://ogdl.org/

* https://treenotation.org/

I wondered this too. Magic behavior is the opposite of what I’d want from Jevko. At that point I may as well use s-exps.

Reply on news.ycombinator.com