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.


About the language - if you are making a new data serialization language(NOT markup language. These languages don't actually mark anything up) for DUB, could you please make it support heredocs? This will allow, in the future, to easily add pre-build and post-build scripts directly in the build-file.

Alos - nameless fields scare me. They mean that ASON is not a schema-less format - and schema-less-ness is one of the most important features of languages like JSON, XML and YAML. I accept it if consumers break when suppliers remove fields - but nameless fields mean that consumers might break when the supplier added fields in the middle or reordered fields. This makes ASON a schema-bound format - and developers that choose schema-bound formats, usually care about compactness that ASON does not supply(since most the syntax is one of schema-less formats, it's very verbose compared to schema-bound formats).


At any rate, it would be nice to have the ASON parser as a DUB package before making it the official language for DUB build-files.

On Monday, 25 At 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/

Have you considered TOML? Rust's cargo uses it; it's very clean IMO. Like an extension to INI.

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.

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

>
> About the language - if you are making a new data serialization language(NOT markup language. These languages don't actually mark anything up) for DUB, could you please make it support heredocs? This will allow, in the future, to easily add pre-build and post-build scripts directly in the build-file.
>

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


> Alos - nameless fields scare me. They mean that ASON is not a schema-less format - and schema-less-ness is one of the most important features of languages like JSON, XML and YAML. I accept it if consumers break when suppliers remove fields - but nameless fields mean that consumers might break when the supplier added fields in the middle or reordered fields. This makes ASON a schema-bound format - and developers that choose schema-bound formats, usually care about compactness that ASON does not supply(since most the syntax is one of schema-less formats, it's very verbose compared to schema-bound formats).
>

Yes when you start using nameless fields your data now needs a schema.  And I had the same concerns you mentioned when adding/removing fields. That's why I recommended the only fields that DUB should make nameless are the "name" fields on some objects.  However, this is not important, completely dismissing the nameless fields feature for DUB would be completely reasonable as well.

>
> At any rate, it would be nice to have the ASON parser as a DUB package before making it the official language for DUB build-files.

I'm writing it now for other projects of mine.

On Monday, 25 August 2014 at 22:21:49 UTC, Weaseldog wrote:
> On Monday, 25 At 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/
>
> Have you considered TOML? Rust's cargo uses it; it's very clean IMO. Like an extension to INI.

TOML was one of the candidates I looked at.  I like it.  The biggest advantage that ASON would have over TOML for DUB is it is a superset of JSON.  TOML has it's own advantages, I personally wouldn't mind using it.

On Mon, Aug 25, 2014 at 4:08 PM, Jonathan Marler via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Monday, 25 August 2014 at 22:21:49 UTC, Weaseldog wrote:
>
>> On Monday, 25 At 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/
>>>
>>
>> Have you considered TOML? Rust's cargo uses it; it's very clean IMO. Like an extension to INI.
>>
>
> TOML was one of the candidates I looked at.  I like it.  The biggest advantage that ASON would have over TOML for DUB is it is a superset of JSON.  TOML has it's own advantages, I personally wouldn't mind using it.
>


If you are going to use a superset of JSON (which I heartily agree with) then should just go ahead and use one of the many existing ones rather than rolling yet another.

Google turns up quite a few, pretty much all of which are equivalent to ASON in features.  Find one that has decent support and run with it.

On Monday, 25 August 2014 at 23:00:59 UTC, Jonathan Marler wrote:
>> About the language - if you are making a new data serialization language(NOT markup language. These languages don't actually mark anything up) for DUB, could you please make it support heredocs? This will allow, in the future, to easily add pre-build and post-build scripts directly in the build-file.
>>
>
> 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, after parsed, is no different from a regular string. But isn't ASON as well, after parsed(with schema), is no different from regular JSON?

As far as I understand, the point of ASON is to make the build files more human readable and writeable. Heredoc do the same thing - if you have a long script(a shell script, or one in a hosted scripting language, or even D code that'll be ran with rdmd) it's hard to write it in a regular quoted string, because they don't support newlines(you have to use '\n') and you need to be careful not to use the quote in the script itself(unless you escape them). Heredoc makes writing these scripts more straightforward.


>> Alos - nameless fields scare me. They mean that ASON is not a schema-less format - and schema-less-ness is one of the most important features of languages like JSON, XML and YAML. I accept it if consumers break when suppliers remove fields - but nameless fields mean that consumers might break when the supplier added fields in the middle or reordered fields. This makes ASON a schema-bound format - and developers that choose schema-bound formats, usually care about compactness that ASON does not supply(since most the syntax is one of schema-less formats, it's very verbose compared to schema-bound formats).
>>
>
> Yes when you start using nameless fields your data now needs a schema.  And I had the same concerns you mentioned when adding/removing fields. That's why I recommended the only fields that DUB should make nameless are the "name" fields on some objects.  However, this is not important, completely dismissing the nameless fields feature for DUB would be completely reasonable as well.

Using the nameless fields in DUB is not the problem - DUB has a well defined schema with a well defined single source of authority. If you want to see ASON used as a data transfer format(like JSON) then these nameless fields will be problematic.

On Tuesday, 26 August 2014 at 00:12:37 UTC, Idan Arye wrote:
> On Monday, 25 August 2014 at 23:00:59 UTC, Jonathan Marler wrote:
>>> About the language - if you are making a new data serialization language(NOT markup language. These languages don't actually mark anything up) for DUB, could you please make it support heredocs? This will allow, in the future, to easily add pre-build and post-build scripts directly in the build-file.
>>>
>>
>> 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, after parsed, is no different from a regular string. But isn't ASON as well, after parsed(with schema), is no different from regular JSON?
>
> As far as I understand, the point of ASON is to make the build files more human readable and writeable. Heredoc do the same thing - if you have a long script(a shell script, or one in a hosted scripting language, or even D code that'll be ran with rdmd) it's hard to write it in a regular quoted string, because they don't support newlines(you have to use '\n') and you need to be careful not to use the quote in the script itself(unless you escape them). Heredoc makes writing these scripts more straightforward.
>
>
>>> Alos - nameless fields scare me. They mean that ASON is not a schema-less format - and schema-less-ness is one of the most important features of languages like JSON, XML and YAML. I accept it if consumers break when suppliers remove fields - but nameless fields mean that consumers might break when the supplier added fields in the middle or reordered fields. This makes ASON a schema-bound format - and developers that choose schema-bound formats, usually care about compactness that ASON does not supply(since most the syntax is one of schema-less formats, it's very verbose compared to schema-bound formats).
>>>
>>
>> Yes when you start using nameless fields your data now needs a schema.  And I had the same concerns you mentioned when adding/removing fields. That's why I recommended the only fields that DUB should make nameless are the "name" fields on some objects.  However, this is not important, completely dismissing the nameless fields feature for DUB would be completely reasonable as well.
>
> Using the nameless fields in DUB is not the problem - DUB has a well defined schema with a well defined single source of authority. If you want to see ASON used as a data transfer format(like JSON) then these nameless fields will be problematic.

ASON single-quoted strings support any character inside them except unescaped single-quotes and unescaped backslashes.  You can put raw newlines in a single-quoted string.

> If you are going to use a superset of JSON (which I heartily agree with)
> then should just go ahead and use one of the many existing ones rather than
> rolling yet another.
>
> Google turns up quite a few, pretty much all of which are equivalent to
> ASON in features.  Find one that has decent support and run with it.

Yes there are some reasonable ones out there.  I would be happy using some of the other JSON variants.  FWIW, here's what makes ASON unique from other JSON variants:

1. Singular named list elements

  Helps solve the deep nesting issue with DUB package files.

2. Supports nameless fields

  This is an interesting feature that isn't very useful for DUB but could be very useful for other applications.  I designed ASON to be useful in the general case so it could be more widely accepted.

3. Supports tables

  As a data interchange format, this feature can really cut down on the size and maintenance of long lists of objects.  Another feature that could make ASON more useful in general cases.

For the details on each of these features, see the ASON spec: https://github.com/marler8997/mored/wiki/ASON-(Application-Specific-Object-Notation)

On Mon, 25 Aug 2014 19:26:59 +0000
Gary Willoughby via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Why are comments and non quoted key names needed?
'cause people are not computers. let's think about people first.