On Tuesday, 26 August 2014 at 20:18:10 UTC, Marc Schütz wrote:
> On Tuesday, 26 August 2014 at 18:35:55 UTC, Jeremy Powers via Digitalmars-d wrote:
>>>
>>>
>>> I agree. Those would be the points with most impacts. However, the
>>>> outcome would be quite far away from standard JSON, so we would really be
>>>> talking about something like ASON or SDL already.
>>>>
>>>
>>> There are some beginnings like this one:
>>>
>>> http://json5.org/
>>>
>>
>> Here's another, that supports tables:
>> https://github.com/krisnye/ion
>>
>> Unfortunately there doesn't seem to be any decently popular winner of the
>> 'extended JSON' language, apparently most are fine with just adding
>> comments.  YAML might be a choice, but I find it diverges a bit too far
>> (and I'm not a fan of significant whitespace).
>
> Well, ion already has that in its name: "indented object notation" :-(
>
> Basic YAML is not so bad (apart from significant whitespace, which I also dislike), but the full specification is surprisingly complicated (properties, tags, lots of different ways to format text...). Even though it wouldn't be utilized in most cases, these features would still need to be supported.
>
> SDL is preferable IMO.

Since YAML is common enough to have implementations for most popular programming languages, supporting it's complicated features should not be a problem.

Am Tue, 26 Aug 2014 13:47:05 +0300
schrieb ketmar via Digitalmars-d <digitalmars-d@puremagic.com>:

> On Tue, 26 Aug 2014 10:36:14 +0000
> eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> > Not exactly that, but look here two approaches for introducing comments in standard JSON:
> they both 'hacks'. and i'm pretty sure that most people who using JSON never bother to read specs, they just expect it to work "like javascript". i myself wasn't aware about JSON limitations when i was writing my own JSON parser, so my parser allows comments and unquoted field names from the beginning.

It depends on the personality of the person looking into
it. Diligent people, when faced with something that looks like
something else, first drop that notion to avoid taking
incorrect shortcuts subconsciously. Then they read the official
documentation until they can't imagine any more questions
and corner cases of the kind "Is there a length limitation for
numbers? How do i deal with overflow? Are other encodings than
Unicode allowed?"

But in the end it comes down to the robustness principle:
Be conservative in what you do,
be liberal in what you accept from others.

-- 
Marco

On 8/26/2014 1:43 PM, eles wrote:
> On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig wrote:
>> Am 26.08.2014 15:37, schrieb eles:
>>> On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis wrote:
>>>> On Monday, 25 August 2014 at 18:31:42 UTC, Marc Schütz wrote:
>>>
>
>> additional alternative format
>
> SDL or D
>

D's an interesting option but it utterly fails the KISS test. All it would do is provide many tempting and creative ways to accidentally obfuscate the package description file. And then there's meta-mess of needing the right compiler version to properly handle a given package. Blech.

On 8/25/2014 6:14 PM, Idan Arye 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/
>>
>
> 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?

...They *continue* writing to dub.json just as before?

I don't see the problem. "dub describe" isn't going to magically start failing just because it was a machine that wrote to dub.json instead of a human.

You did catch the part where people keep saying that support for JSON is *not going anywhere*, right?

> 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?

Again, use "dub describe" to read the data, then write to "dub.{whatever}".

> I think we need a command like `dub normalize` that'll

"dub describe"

> convert the dub.json file into a pure JSON file

"dub describe"

>that has exactly the
> same data, so IDEs could call it before loading dub.json.
>

I don't see the problem.

On 8/25/2014 7:00 PM, Jonathan Marler wrote:
>
> I am not familiar with the term "herdoc".  After a quick google, it
> looks like it refers to a way of escaping the language.  Is this not
> something that a single-quoted string couldn't handle? You would still
> need to escape single-quotes and back-slashes, but it comes close.
> However, I wouldn't be against adding a special character sequence to
> support this (Maybe '<<' or something).
>

Heredoc is just a raw string that doesn't choke on embedded newlines.

And often the "end of string" delimiter is customizable so you don't have to worry about escaping the quotes or anything.

On 8/26/2014 4:53 AM, eles wrote:
> On Tuesday, 26 August 2014 at 07:12:40 UTC, ponce wrote:
>> - SDL is _whitespace sensitive_
>
> I don't like this.
>

That's somewhat misleading.

More accurately, SDL is newline-delimited (with backslash line continuation). That's pretty darn simple and has an age-old history. It's not like we're talking weird Python/JavaScript rules or anything here.

The only thing that does trip people up is that the existence of { and } in the syntax makes people think "C-family and therefore freeform". And then it isn't, so that makes them angry. "Yeeargh! Hulk Not Want!" Well...or something vaguely sorta kinda like that ;)


>> - 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.
>

Personally, I find those, along with the syntax noise, to be the three core pillars of JSON pain.


>> - XML is XML. I find it actually OK.
>
> I would support this. Yes, is verbose, we know that. But is a very solid
> foundation.
>

XML is the spawn of satan. And not the cool "rock n roll", "heavy metal" kind of satan, or the bumbling lovable DBZ "Mr. 'Hercule' Satan" either, but the "hey, let's write a commercial webserver in shell scripts" kind of raw pulsating evil.

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:
>>> 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 believe whitespace sensitivity is a Good Thing for human-readable formats. Date type is annoying but simply omitting its support sounds more reasonable than going with brand new format.

On 8/26/2014 3:12 AM, ponce wrote:
>
> - I've actually tested TOML. It has a weird edge case for tables of
> hashes and hashes of tables,

I'm not doubting you, but I'm curious about this. Can you elaborate?

> it's not composable syntax

This too?

> and the worst of
> the bunch as far as I'm concerned. TOML is also whitespace sensitive.

Hmm, ok now I'm wondering if we're even looking at the same TOML. I'm looking at this:

https://github.com/toml-lang/toml

Or by "whitespace sensitive" are you just talking about being newline-delimited? For a data language, that doesn't really bother me. Or have I overlooked something in TOML's description?

On Wednesday, 27 August 2014 at 02:39:56 UTC, Dicebot wrote:
> I believe whitespace sensitivity is a Good Thing for human-readable formats. Date type is annoying but simply omitting its support sounds more reasonable than going with brand new format.

To elaborate a bit more about whitespace and stuff - JSON is not going anywhere and will be available for those who prefer conservative syntax. From a new one I do indeed want minimal amount of formatting boilerplate and focus on content -> it _must_ be whitespace sensitive

On 8/26/2014 10:39 PM, Dicebot wrote:
> On Tuesday, 26 August 2014 at 07:12:40 UTC, ponce wrote:
>>
>> - SDL is _whitespace sensitive_ and have a date data-type which
>> complicate the parser for little good. Lack of parsers ensues.
>
> I believe whitespace sensitivity is a Good Thing for human-readable
> formats. Date type is annoying but simply omitting its support sounds
> more reasonable than going with brand new format.

Yea, I don't think anything in dub's configuration even involves date/time at all (aside from maybe copyright, but that'd need to be a string anyway), so the existence of a date type in SDL is entirely irrelevant.

It's not as if Sonke would actually need to write (or maintain) any date parsing code. There's already two SDL parsers for D. Dub would just be using one of those.