Before we implement SDL package format for DUB

[Jonathan Marler via Digitalmars-d]

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.