>please don't invent yet another markup language for developers to learn. Especially as this new language is only relevant to dub. Honestly it would seriously make me not want to use dub.

>Please no custom markup languages when existing ones are good enough.

I am totally agree! JSON or SDL are really enough! Please do not add new language!

On Monday, 25 August 2014 at 22:32:36 UTC, Dicebot wrote:
> On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:
>> Hello everyone,
>>
>> I've been working on SDL support for DUB and wanted to get some people's opinions on whether we should really use SDL.  I've posted my thoughts here: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
>
> Please no custom markup languages when existing ones are good enough.

Are they good enough really? I've tested it all.

- SDL is _whitespace sensitive_ and have a date data-type which complicate the parser for little good. Lack of parsers ensues.
- I've actually tested TOML. It has a weird edge case for tables of hashes and hashes of tables, it's not composable syntax and the worst of the bunch as far as I'm concerned. TOML is also whitespace sensitive.
- JSON has no comments, also trailing commas are disallowed (but allowed in DUB which push constraints on foreign parsers)
- XML is XML. I find it actually OK.

To me ASON (minus unnamed fields minus unquoted values :) ) is certainly a better configuration format, and being JSON compatible doesn't hurt.

On Monday, 25 August 2014 at 19:52:56 UTC, Jonathan Marler wrote:
>
> Maybe if DUB started using it...other tools and software would look into it?

That was already the idea behind using SDL, since it's seldom used in the wild.

On Tuesday, 26 August 2014 at 07:12:40 UTC, ponce wrote:
> On Monday, 25 August 2014 at 22:32:36 UTC, Dicebot wrote:
>> On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:

> - SDL is _whitespace sensitive_

I don't like this.

> - JSON has no comments, also trailing commas are disallowed

To me, these are not very bad limitations. Yes, I would like comments, but I could leave without, especially if fields have meaningful names.

> - XML is XML. I find it actually OK.

I would support this. Yes, is verbose, we know that. But is a very solid foundation.

My vote would go for JSON and/or XML (why not both formats?).

But I am against a new language. We have enough...

On Tue, 26 Aug 2014 08:53:44 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > - XML is XML. I find it actually OK.
> I would support this. Yes, is verbose, we know that. But is a very solid foundation.
any homemade format or character soup is better than XML. it's not only verbose, it's hard to write, hard to read and hard to parse. the worst from all worlds.

On Tuesday, 26 August 2014 at 09:12:36 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 26 Aug 2014 08:53:44 +0000
> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> the worst
> from all worlds.

Granted, but still the "most standard" and you find a lot of standard tools to process it.

Are the drawbacks of JSON so big? Why to move away from it and, more, towards another, custom-built, markup language. Isolating D even more from the rest of the world?

Am 26.08.2014 00:14, schrieb Idan Arye:
> On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler wrote:
>> Hello everyone,
>>
>> I've been working on SDL support for DUB and wanted to get some
>> people's opinions on whether we should really use SDL.  I've posted my
>> thoughts here:
>> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/
>>
>
> You said that "The standard way to read a dub package description is to
> use the output of "dub describe", not to parse dub.json directly", but
> what about tools that *write* to dub.json? Currently, if an IDE wants to
> use DUB behind the scenes as it's build system it can parse dub.json and
> modify it as it wishes, and that should even work if someone modified
> dub.json by hand. But what if someone modifies dub.json by hand and adds
> ASON stuff to it? I think we need a command like `dub normalize` that'll
> convert the dub.json file into a pure JSON file that has exactly the
> same data, so IDEs could call it before loading dub.json.

That's a good point. Although I think that IDEs would be best off limiting themselves to JSON, because not keeping comments and formatting for any more complex format may be an issue.

However, SDL has on it's plus side that there are implementations for Java, .NET, D and Ruby. So most popular IDEs *could* relatively easily add support. Any IDE that can integrade D libraries can also use DUB as a library.

On Mon, 2014-08-25 at 16:40 +0000, Jonathan Marler via Digitalmars-d wrote:
> Hello everyone,
> 
> I've been working on SDL support for DUB and wanted to get some people's opinions on whether we should really use SDL.  I've posted my thoughts here: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/


With a bit more work this would be a good notation for a D plugin for Gradle!

I can imagine with Groovy implementing this language would be trivial.

It would be splendid to have a build specification for Dub that also worked with Gradle.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 26 Aug 2014 09:32:09 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Are the drawbacks of JSON so big? Why to move away from it
i don't know too. i think that it's enough to add three features to
current json parser to be happy:
1. comments, both '//' and '/* */.
2. unquoted field names.
3. ignoring trailing commas.

ah, optional 4th feature: allow omiting highest-level curly brackets.

this additions will not break any existing json definitions, but allow us to use some human-friendly features.

Am 25.08.2014 18:40, schrieb Jonathan Marler:
> Hello everyone,
>
> I've been working on SDL support for DUB and wanted to get some people's
> opinions on whether we should really use SDL.  I've posted my thoughts
> here:
> http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/

Just sharing my (overdue) more detailed view on this:

Pros:
 - Easier to parse
 - Slightly nicer handling of "enum" values due to quote-less strings
 - Whitespace insensitive

Cons:
 - I *really* dislike the "application specific"/"nameless tags" part
   of it, because generic handling always was one of the basic
   prerequisites for me
 - It's a still custom format in practice, even without the "application
   specific" part - except if it (ever) becomes more widespread
 - Confusing wealth of syntax possibilities when punctuation can be
   omitted, I'd very much prefer one way to express one thing
 - A language with neither newline sensitivity, nor required tag
   terminators, I think is bound to give very bad error message in
   certain situations
 - Quote-less strings, especially when mixed with nameless tags or
   omitted punctuation can be very confusing
 - Quote-less strings which are allowed to contain punctuation are
   confusing, because the punctuation can easily be confused as being
   part of the ASON syntax itself

To me, this currently outweighs by far the disadvantages that SDL has:

 - Sensitive to newlines, but not other whitespace. This is convenient,
   although I'd prefer a mandatory semicolon (which ASON doesn't have
   either)
 - Some parser complexities not needed for DUB (e.g. date/time types).
   I'm more or less "meh" about this. It can be nice to have for other
   uses (configuration files) and doesn't really hurt either.

But most important is that SDL is already in use for other (non-minor) projects [1] and thus has probably much better chances to become more widespread than "yet another JSON extension format" (this is not critique of the approach of extending JSON, but rather of how the average observer would likely perceive a format advertised that way).

Continuing on that point, an important point for choosing a format was to minimize the amount of DUB specific syntax to learn. So if somebody has to learn a new language for that, it should at least also be useful in other places and any newly invented format is just much less likely to generally useful than something that already has some level of popularity.

[1]: http://sdl.ikayzo.org/display/SDL/Projects+Using+SDL