Am 27.08.2014 11:49, schrieb eles:
> On Wednesday, 27 August 2014 at 09:33:19 UTC, Sönke Ludwig wrote:
>> Am 27.08.2014 10:29, schrieb eles:
>>> On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky wrote:
>>>> On 8/27/2014 1:40 AM, eles wrote:
>>>>> On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote:
>>>>>> 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:
>
>> And you will have to pay the price for a rocket and have to rebuild
>> parts of your house every time you kill a fly ;)
>
> If it's 3 AM and you cannot yet sleep because that fly is annoying you,
> I bet you'll consider that's a very small price to pay...

But the next morning you'll wake up and regret what you did that night

Am 27.08.2014 11:47, schrieb eles:
> On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote:
>> Am 27.08.2014 10:02, schrieb Kagamin:
>>> On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky wrote:
>
>> The reason to search for an additional format is to make it more
>> convenient and readable for human interaction.
>
> There is also this quest:
>
> http://www.gnu.org/software/recutils/
>

It seems to be missing built-in array types and nested maps/objects. It *looks* like it would require defining so many custom types that it would become a de-facto custom format. Still looks interesting in general, though.

On Wednesday, 27 August 2014 at 11:29:32 UTC, Sönke Ludwig wrote:
> Am 27.08.2014 11:49, schrieb eles:

> But the next morning you'll wake up and regret what you did that night

Well, that saying could be applied to so many things in life...

On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote:
> I just had an "epiphany".  I believe that if I added attributes to ASON, it would be a true superset of SDL.  Meaning any SDL file would also be a valid ASON file.  What kind of monster did I create!  I accidently created a language that serves as both a superset of JSON and SDL?  I didn't think that would be possible, expecially with such a little amount of extensions to JSON.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
- Antoine de Saint-Exupery

On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote:
> On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote:

> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
> - Antoine de Saint-Exupery

Why to not use a classic?

"Within C++, there is a much smaller and cleaner language struggling to get out."

He meant, of course, D. We knew it all along.

On Monday, 25 August 2014 at 22:14:59 UTC, Idan Arye 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.

If it's something non-trivial, it should be put into separate file at least to get dedicated syntax highlighting and editor support.

On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote:
>> That's justified, because SDL fails to not surprise. Curly brace
>> syntaxes are not line-delimited not requires backslash line continuations.
>
> Like JavaScript for example?

You mean its feature where it can work without semicolons? Yeah, that's a silly feature, but it's not forced on everyone. I have never hit it in my code.

> The reason to search for an additional format is to make it more convenient and readable for human interaction. XML wouldn't structurally a bad choice, but is awful because of it's syntactical overhead.

Aren't people more concerned with writing XML rather than reading? Syntax makes for easier reading and tedious writing.
And overhead is not really big:
"menu": { "id": "file", "value": "File" }
<menu id="file" value="File"/>
It's even shorter!

On Wednesday, 27 August 2014 at 05:40:51 UTC, eles wrote:
> On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky wrote:
>> All it would do is provide many tempting and creative ways to accidentally obfuscate the package description file.
>
> I agree partially with this, this is why I am not pushing for D. A declarative language seems to be more appropriate in this case.
>
Ideally we wouldn't even need that, but reality is rarely so kind.  I suppose if we can't be sufficiently Perl-like, maybe Portage-like is the next best thing. :/

Thought dump:
The DUB package specification is versioned, right?  So, in the vein of the Package Manager Specification, for a given...let's call it "DUBAPI version"... provide higher-level functions that abstract away things that are common or things that are tricky to get right if you try to always do them manually.  Package them in modules that can be imported and use the DUBAPI version within the module to select version-specific behaviour.  For those of stern fortitude, an ugly ebuild-like thing; a...uhm, "dubuild":

DUBAPI=1;
import dub.autotools;
import dub.git;
import dub.utils : patch;

DESCRIPTION = "Plugin providing semi-solids for bread";
HOMEPAGE = "http://toa.st/spread";
LICENSE = "zlib";
PHOBOS_VERSION = "<=2.065"; // TODO: fix the failure
GIT_REPO_URI = "http://github.com/toast/spread";
GIT_BRANCH = "butter"; // Vars defined in the dub.git module
DEPEND = {">=libyeast-1.3", ">=libbread-2.2" }; // Build-time dependency

// Each of these phase functions overrides a default.
// If it doesn't need overridden, the default is used.
src_unpack(){
    git_fetch(GIT_BRANCH); // No argument gets master branch
    patch("files/melt_butter.patch"); // Apply our local patch
}

src_configure() {
    assert(autoreconf(), "configure failed!"); // Die if this fails.
}

src_install() {
    dub_install("~/toast/plugins/"); // Non-standard location
}

post_install() {
    dublog("Activate the spread plugin under Tools -> Options -> Plugins");
}

NOTE: I want to believe this is overkill and we'll never need to consider anything even resembling this route, but experience makes that hard.

-Wyatt

On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote:
> On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote:
>> I just had an "epiphany".  I believe that if I added attributes to ASON, it would be a true superset of SDL.  Meaning any SDL file would also be a valid ASON file.  What kind of monster did I create!  I accidently created a language that serves as both a superset of JSON and SDL?  I didn't think that would be possible, expecially with such a little amount of extensions to JSON.
>
> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
> - Antoine de Saint-Exupery

On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby wrote:
> On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler wrote:
>> I just had an "epiphany".  I believe that if I added attributes to ASON, it would be a true superset of SDL.  Meaning any SDL file would also be a valid ASON file.  What kind of monster did I create!  I accidently created a language that serves as both a superset of JSON and SDL?  I didn't think that would be possible, expecially with such a little amount of extensions to JSON.
>
> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
> - Antoine de Saint-Exupery

Nice quote, but unfortunately there's no such thing as a perfect programming language or a perfect data format.  JSON is dirt simple and popular.  However using strict JSON for build configuration prevents users from commenting out sections temporarily, and also rejects text that can be understood by a human but doesn't follow JSON's strict rules.  It also becomes very unwieldy when any amount of nesting is involved.  Then again, when you start writing data formats that are easier to write for humans, you start getting complicated.

IMO, ASON has a nice balance between being very simple and very nice for humans to write/maintain.  I also think there are some JSON variants that do the same thing, json5 looks nice, but it doesn't support the SingularName feature that ASON does which would fix the nesting issue.

On Wednesday, 27 August 2014 at 13:32:56 UTC, Kagamin wrote:
> On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig wrote:
>>> That's justified, because SDL fails to not surprise. Curly brace
>>> syntaxes are not line-delimited not requires backslash line continuations.
>>
>> Like JavaScript for example?
>
> You mean its feature where it can work without semicolons? Yeah, that's a silly feature, but it's not forced on everyone. I have never hit it in my code.
>
>> The reason to search for an additional format is to make it more convenient and readable for human interaction. XML wouldn't structurally a bad choice, but is awful because of it's syntactical overhead.
>
> Aren't people more concerned with writing XML rather than reading? Syntax makes for easier reading and tedious writing.
> And overhead is not really big:
> "menu": { "id": "file", "value": "File" }
> <menu id="file" value="File"/>
> It's even shorter!

Yes writing it is what I'm concerned about.  If you like XML though, you're gonna love SDL:)

menu id="file" value="File"

It's even shorter again!

There's 1 to 1 mapping between SDL and XML, SDL just uses curly-braces and newlines instead of the <angle-brackets>.