SDLang – Simple Declarative Language | Hacker News Reader

SDLang – Simple Declarative Language

sdlang.org

56 pointsbpierre10 comments

Here is what the SDLang example would look like in EDN (Extensible Data Notation), a subset of Clojure:

    ; Maps are denoted as key-value pairs inside curly brackets:
    {:title "Hello, World"}
    
    ; Vectors are denoted by square brackets:
    [:bookmarks 12 15 188 1234]
    
    ; Or you can use a map with a keyword that maps to a vector:
    {:bookmarks [12 15 188 1234]}
    
    ; Maps are collections of key-value pairs:
    {:author  "Peter Parker"
     :email   "peter@example.org"
     :active? true}
    
    ; Data structures are heterogeneous and nest:
    [:contents
     [:section "First section"
      [:p "This is the first paragraph"]
      [:p "This is the second paragraph"]]]
    ; ^ Hiccup actually renders these to HTML.
    
    ; Everything is an expression, so strings just work:
    "This text is the value of an anonymous node!"
    
    ; A matrix is just a vector:
    [1 0 0
     0 1 0
     0 0 1]
    
    ; Or you could partition it into rows:
    [[1 0 0]
     [0 1 0]
     [0 0 1]]

https://github.com/edn-format/edn

I first saw .sdl used by a D package. I liked it as an alternative to XML where there is a hierarchy, beginning and end tags (sdl uses {}) and multiple children at the same level, but at this point, the only reason why I decided to use it in my D projects was because the API to parse it is more convenient than using dxml imo.

It looks nice! But it's still missing a semantics. When are two values equal? When are they distinct? JSON and most other formats also have no real semantics. XML is a notable exception, with XML infoset defining a semantics for the syntax. See also https://preserves.gitlab.io/preserves/why-not-json.html

> JSON and most other formats also have no real semantics.

This is true, but due to its origin I think we have a weak agreement over the JSON data model: it is a JavaScript value unless ambiguous. We do expect dotted number literals represent IEEE 754 binary64 numbers (importantly, this is pretty much the only case that excess precision do not alter the value), undotted number literals of the range (-2^31, 2^31) (exclusive) represent 32-bit integers, string literals with no lone surrogates and no unescaped U+2028/U+2029 represent Unicode strings, objects with no duplicate keys represent a partial mapping from strings to values.

It is very common to avoid a valid but ambiguous and/or problematic subset of JSON, e.g. most encoders avoid unescaped U+2028/U+2029. Given that I think it is more useful to have a profile of JSON with the defined semantics than to have a substantially different format. Preferably that should be included to the JSON standard (RFC 8259, ECMA-404, ISO/IEC 21778 or whatever) itself.

Note that this link was also submitted to HN by its own: https://news.ycombinator.com/item?id=24946268

I feel like the number one reason to use XML is the mixed content. This is also why XML and derived formats (the xml-y parts of HTML) are so good as markup languages.

So this:

    p { 
      "mixed"
      img href="test.png"
      "content"
    }

is worse than:

    <p>mixed<img href="test" />content</p>

... at least as markup, since having to wrap all text in quotes is tedious.

The other language I know of that provides "natural" mixed content is scribble [1], but I think the only implementation that I know of is the racket one, since it is so tied to racket semantics.

If you take mixed content away from XML, then you may as well use one of the myriad of existing IDL languages, no?

1: https://docs.racket-lang.org/scribble/getting-started.html

The funny thing is that all of these examples are valid Oil syntax [1], since I added Ruby-like blocks with { } to shell. A block can be evaluated to a JSON-like data structure, e.g. this:

    server foo {
      port = 80
      root = '/'
      section bar {
        ...
      }
    }

could become:

    {name: "foo", port: 80, root: "/", "bar": { ... } }

And you can use if statements and loops to generate repetitive structures! Rather than using textual templating.

(The syntax is all there, but the evaluation is incomplete -- contact me if you want to help, and influence the API/language design)

-----

The shell is a logical place for configuration, because shells start processes that need configuration. Configs are often passed in as environment variables or flags.

The syntax can support:

    title "Hello World"  # like SDLang

in addition to

    title = "Hello World"

although I'm still wondering if we should enforce one or the other for consistency. The latter is more flexible in Oil because you have arbitrary expressions on the RHS.

[1] http://www.oilshell.org/release/latest/doc/idioms.html

https://lobste.rs/s/6oxpe3/s_lot_yaml#c_mje209

Awesome, maybe the best thing I’ve seen since EDN. I might have to adopt this if EDN is too hard for my audience. Looks like converting to native Clojure data right after reading and back before display/storage should be easy enough.

Any concept of namespaces? I read the page, saw none. I have this mapping of XML to EDN that I want to apply, maybe port the stock XMPP transport. (I’ve a Patreon if this sounds good, same handle).

It mentions namespaces in the last code block on the page.

    // Namespaces are supported
    renderer:options "invisible"
    physics:options "nocollide"

What are these emerging declarative languages bringing to the table that will make people want to switch from what they’re using now? SDLang looks neat and clean, but to me it looks like JSON would get the same work down in the same amount of text. If your only gripe with existing markup languages is simply “I don’t like the syntax”, that’s a perfectly valid reason to switch. But are there any good objective reasons one should switch?

Let me bite this:

- JSON is massively underspecified. Its specification(s) alone can't produce multiple conformant implementations, as famously demonstrated by [1].

- JSON by its own is annoying to write because it doesn't support trailling commas nor comments. Most uses of JSON as configuration format (e.g. Visual Studio Code) would actually use (unspecified) extensions to make it more palatable.

- JSON has an undefined data model, generally thought to be a version of JavaScript values but not exactly. Have you ever dealt with 64-bit integers?

- JSON's (probable) data model lacks many important types, most notably a set, a true mapping with non-string keys and a byte array. You are likely to suffer if you need them. Disjunctive (or sum) types like `Ok(value) | Err(error)` are also painful to handle.

- JSON doesn't have a defined canonicalization algorithm, almost surely required by cryptographic protocols (and we live in the world where they are a thing). There are tons of mutually incompatible proposals.

- Being a subset of JavaScript, JSON is hard to parse efficiently and doesn't allow random access. Note that this is not unique to JSON and shared by many other formats including binary ones, but JSON is so ubiquitous that it is often used for inappropriate cases. It is not as impossible as simdjson [2] demonstrates (and multiple redundant syntaxes of JSON are actually beneficial for simdjson), but it's better to use random-accessible formats if you need performance.

- Being a subset of JavaScript, JSON is huge. Even much so if you embed it to other JSON (doubles quotes). Again, it's a problem mainly because of inappropriate uses. Pretty much any binary format will beat JSON in this regard.

[1] http://seriot.ch/parsing_json.php

[2] https://github.com/simdjson/simdjson

Reply on news.ycombinator.com