SDLang – Simple Declarative Language | Hacker News Reader

SDLang – Simple Declarative Language

sdlang.org

75 pointssmartmic33 comments

Having `true/false/on/off/null`, 4 different comment styles and 5 numerical types screams anything except for 'Simple' to me.

It may be a fine language, but it seems like it needs a new name. Maybe 'YAYAML' to highlighting its complexity.

I guess they mean simple syntax.

Null is very different than true and false, equivalence is really frustrating to deal with.

k.d. lang, for komplex declarative language

As a user of SDLang.. not a huge fan of it, IMO. Dub (the D package manager) uses SDLang as one of the two formats that you can use to configure projects (those two being SDLang and JSON), and I often find myself converting every project to using the JSON format as there is virtually no tooling (in most languages) for parsing SDLang. I've recently started using TOML instead, and I have nothing but good things to say about it.

Is just the tooling the problem, or have you run into other issues?

I’m no fan of JSON as a configuration language, but I tried using SDLang with dub and quickly returned to JSON.

Dub would feel slightly (slightly!) more polished if it used a more common package format. TOML would be a good choice.

I honestly don't know why people don't adopt a slightly better json at this point if we're going to invent weird new formats anyways. Some kind of macro language with better syntax would be ahead by miles, and able to plug into anywhere that uses JSON very easily.

KDL is a variant of SDLang that’s worth checking out.

https://github.com/kdl-org/kdl

It seems like the date/time format is ambiguous, since a date followed by a time could be interpreted either as a single date-time value or a date value followed by a time value.

Date/time specification is incredibly hard. However hard you think it is, it's actually a "little" harder.[1]

I'd guess that someone formulating their own date/time format is actually evidence that they don't understand what a problem it is and so their format is wrong.

[1] https://en.wikipedia.org/wiki/Time_formatting_and_storage_bu...

In the present case the problem is solely related to using whitespace both as a value separator and also within a value, where both “halves” of the value are also valid values in their own right. It would have been similar if they defined a complex-number type whose syntax consists of the real and imaginary part just being separated by whitespace. The issue has nothing to do with the conceptual particularities of date and time.

Sure, I'd just offer the fundamental difficulty is date/time is a sum of "trivial" problems like this. That a date by itself and a time by itself can be "moments in time" is just one of many difficulties around date-time. IE, none of the particularities (other examples being the irregularities of legal month/day combinations) seem "conceptual".

The relevant conceptual difficulties are the distinction between calendar dates plus time-of-day on the one hand vs. physical time (number of actual seconds) on the other hand, and the way they relate to each other via time zones, DST and leap seconds. To a lesser degree, also the fact that months have different lengths, and cultural differences like start of the week, week numbers etc., and finally date formatting. Most of these are really conceptually tied to time keeping. How to create an unambiguous syntax really isn’t.

It doesn't seem worth it to figure out time/date representation at the data layer like this.

Rigid definition of time stamps leads to incompatible parsers and risks if you need to update how the timestamp works.

Or, store it as a string and deal with it after parsing.

The latter one always wins, hence json's popularity.

Baking it into the data format isn't going to make people treat timestamps right. Probably will do the opposite, really.

Why people insist on not using ISO 8601 (or a subset of it) is beyond me.

Not bad. I prefer edn, but this is certainly an improvement over, say, JSON.

Some link to share about EDN?

Appears to be this https://github.com/edn-format/edn

I like this kind of syntax because it is a lot like how my ad-hoc print/log statements have been printing structured data all along.

For a generic data language, SDLang has some oddly specific features: distinction between 32-bit and 64-bit integers, single and double floats, arbitrary strings and base64, 3 single-line comment styles, multiple ways to say booleans.

Smells like leaky abstraction, as if the author has ingrained some requirements of the project they've been working on into SDLang rather implementing them in project-specific code.

Another commenter has linked KDL language which seems to have cleaner design, and can even satisfy more typing use cases than SDLang.

What’s the story on error handling? This has been the downfall of a lot of structured text formats.

This looks clean and very readable. How's the experience on the programming side, though?

Looks interesting, but does it offer any unique features that set it apart from other such languages like JSON, XML, etc.? I see that matrix example, but is it any different from an array? (I couldn't tell from reading the docs.)

Unlike JSON and XML its designed to be human readable and writable. It's more like a better YAML.

So its a competitor to TOML? (or TOML to it, I dunno when this was created)

JSON5 might be a good candidate for these attributes.

I hear this not-for-human comment so often, I really have to second mrtweetyhack's now dead comment and this one. When did this meme start making the rounds?

JSON especially is incredibly human read/writeable and its relative lack of ambiguity is nearly unparalleled., and it's syntax is minicule. YAML is particularly bad in this regard. XML is usually pretty humanly readable, editable too, and has many fewer of the issues around ambiguity, but I sympathize with the sentiment since it can get's out of hand much more readily.

Since when are json or XML not human readable or writable?

Did you reply to the wrong comment?

Yes, sorry.

Wow, unbelievable timing. Was just looking for such spec language. Looking at related ones like libucl, dhall, metadesk, edn, toml. This and KDL as pointed out by @quag seem to fit my needs much better. Thank you both!

For interested readers, EKON [1] proposes yet-another interesting superset for JSON.

[1] https://github.com/ekon-org/ekon

Reply on news.ycombinator.com