I am currently working on DUB to support the new SDL package format. Initially I was very happy to see a new format, especially one that seemed very simple and intuitive. However, after getting intimate with SDL I found that even though it seemed simple and stripped down, it actually has some odd "eccentricities". I wanted to see if there was a language that was as easy to read/write as SDL but didn't have so many odd rules. I spent some time looking at other formats but ended up attempting to write my own. I started with a clean slate and when I was finished I realized that I just made another variation of JSON...so I called it ASON( Application Specific Object Notation). I know that this discussion has already been had here, but I thought this language had enough advantages over SDL that it was worth it to see what people think before we take the final plunge and implement the SDL package format.
The first thing I'll say is that ASON is a superset of JSON, so every JSON file is also a valid ASON file. This means that if DUB were to start using ASON, we could swap out the parser and every DUB package file would still be valid. Furthermore, even though ASON supports different ways to write the same data, it represents the exact same data structures as JSON, so there would be no need to change the build specification. This is not the case with SDL. SDL is basically a variant of XML. Every object in Dub's build specification will require a specification of which fields should be represented as values, attributes or child tags, i.e.
dependency "vibe-d" ">=1.0.0"
// OR
dependency "vibe-d" version=">=1.0.0"
// OR
dependency name="vibe-d" version=">=1.0.0"
// OR
dependency "vibe-d" {
version ">=1.0.0"
}
// There are more variations but you get the idea.
The next critique I have of SDL is it doesn't have a solid specification. It DOES NOT include a grammar and when I attempted to write one it was clear that writing it was not a trivial task. I was in correspondence with the creator of SDL and I brought up many odd corner cases that were not in the specification. He recommended I use the Java/C# implementations to make sure I was following the specification. ASON on the other hand includes a full grammar, complete with visual railroad version (like the one for JSON).
I've included a list of s-ludwig's initial critique of JSON and how each language solves them:
No Comments
- SDL: Supports comments
- ASON: Supports comments
Key names must be quoted
- SDL: Uses "tags" that cannot have quotes
- ASON: Supports non-quoted strings
Commas between fields
- SDL: No Commas
- ASON: Commas are optional, and supports a trailing comma
Easy to learn but verbose
- SDL: Concise and easy to learn as long as you don't do anything odd
- ASON: Concise and easy to learn, especially those familair with JSON
Deep nesting
- SDL: Solves by ammending the specification to specify that list objects can be written a different way
- ASON: Solves using the "SingularName" feature of the language
If you liked SDL you will also like ASON since they look so similar. In fact if you don't use attributes, many SDL files are also valid ASON files. You could say that ASON is what SDL would be if it was based from JSON instead of XML. Here's what the dub package format would look like using ASON:
name "my-package"
description "A package for demonstration purposes"
dependency "vibe-d" {version ">=0.7.13"}
dependency "sub-package" {version "~master", path "./sub-package"}
// command line version
configuration "console" {
targetType "executable"
versions ["ConsoleApp"]
lib-windows ["gdi32" "user32"]
}
// Win32 based GUI version
configuration "gui" {
targetType "executable"
versions ["UseWinMain"]
lib-windows ["gdi32" "user32"]
}
