Hacker News new | ask | show | jobs
by djedr 1322 days ago
The only solution to this war is no commas!

To roughly translate the first example in the article (I shortened the value of `d`):

  svg [ 
    x=[0px]
    y=[0px]
    viewBox=[0 0 21 21]

    path [
      fill=[#FFF]
      stroke=[#146AFF]
      strokeWidth=[2]
      d=[M11.1,1.4l2.4,...]
    ]
  ]
You can remove all whitespace and it's still unambiguous.

It's a perfectly viable lightweight syntax for SVG.

See also https://news.ycombinator.com/item?id=32995047
1 comments
cardanome 1322 days ago
Another example would be Lisp. And yeah generally, fair point.

In Elm though it would cause some ambiguity because of the function call syntax not requiring parentheses. For example:

    [foo bar baz]
Is this a List with three elements or is it one element whose value is a function call on foo with the arguments bar and baz? Who knows. Sure you could have implicit commas on line break but that would be weird.
link
djedr 1322 days ago
Yes, in Elm or Lisp this would be problematic.

In this syntax though it isn't. Anything between brackets like this:

  [foo bar baz]
that does not contain any nested brackets is a simple tree which contains "foo bar baz" as its sole value (called a suffix).

In this syntax whitespace is not a separator.

So you can store a single piece of text in such a simple tree.

Now if you want to have 3 pieces of text you do this:

  [foo][bar][baz]
3 simple trees together -- they are subtrees of a top-level tree.

If you want to have 3 of these you do this:

  [[foo][bar][baz]]
  [[foo][bar][baz]]
  [[foo][bar][baz]]
The linebreaks don't change the tree structure, they are inserted purely for readability.

There are no implicit commas or anything.

Each subtree is also potentially a name-value pair. If you insert names before the opening brackets:

  [x [foo] y [bar] z [baz]]
You have 3 pairs.

The names themselves are also pieces of text (whitespace is not a separator), so you can have names like:

  [my x [foo] your y [bar] their z [baz]]
Still 3 pairs.

Now to turn trees like this into something useful, for example XML/SVG, you'd do a little bit of processing on them, e.g. you could transform the names like so:

  my x [foo] your y [bar] their z [baz]
into:

  <myX>foo</myX><yourY>bar</yourY><theirZ>bar</theirZ>
in this manner you could transform:

  svg [x=[0px] y=[0px] view box=[0 0 21 21] path [
    fill=[#FFF] stroke=[#146AFF] stroke width=[2] d=[M11.1,1.4l2.4,...]
  ]]
into:

  <svg x="0px" y="0px" viewBox="0 0 21 21"><path
    fill="#FFF" stroke="#146AFF" strokeWidth="2" d="M11.1,1.4l2.4,..."
  ></path></svg>
Notice that here I used a convention where names which end with "=" become XML attributes, whereas names which don't become children.

I have used the same convention here (except I don't bother with transforming names with spaces into camelCase): https://github.com/jevko/specifications/blob/master/easyjevk... to generate this HTML file: https://htmlpreview.github.io/?https://github.com/jevko/spec...

Now I intend to write specifications that codify conventions like this into different formats based on this fundamental syntax of square brackets.

It can be useful for all kinds of things. Its advantage is extreme simplicity and flexibility.

BTW, for clarity I have to say that the format that I used here: https://news.ycombinator.com/item?id=32995047 does a bit more transformations -- it actually sometimes treats whitespace as a separator (e.g. in `svg width[391]` space is a separator). That allows for extreme conciseness, but is not necessary and introduces complexity.

link