Before we implement SDL package format for DUB

[Jonathan Marler via Digitalmars-d]

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/

[Gary Willoughby via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
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
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/

I kind of get the feeling you're trying to push dub to use ASON.

My first reaction is, 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. Just pick one of the existing ones, XML, Yaml,
Json, SDL (i've never heard of this one.) and stick with it. All
other package managers seem to do just fine. Don't fix what isn't
broken.

Relevant: http://xkcd.com/927/

Seriously though are you also willing to break all existing
dub.json files? That's 317 (http://code.dlang.org/ as of today)
packages this change is going to mess with. Are you really going
to do that? Just as things are starting to take off?

I'm in favour of just sticking to plain, normal old Json.
Everyone knows it, everyone understands it and everything else
does just fine using it.

[via Digitalmars-d]

On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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.
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/

I kind of get the feeling you're trying to push dub to use ASON.
My first reaction is, 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. Just pick one of the existing
ones, XML, Yaml, Json, SDL (i've never heard of this one.) and
stick with it. All other package managers seem to do just fine.
Don't fix what isn't broken.
Relevant: http://xkcd.com/927/
Seriously though are you also willing to break all existing
dub.json files? That's 317 (http://code.dlang.org/ as of today)
packages this change is going to mess with. Are you really
going to do that? Just as things are starting to take off?
I'm in favour of just sticking to plain, normal old Json.
Everyone knows it, everyone understands it and everything else
does just fine using it.

If only it supported comments...

[Jonathan Marler via Digitalmars-d]

Post by via Digitalmars-d
If only it supported comments...

Yes comments would be amazing...also non-quoted keynames. If we
just added those 2 things to the JSON parser I would be happy:)

[Gary Willoughby via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d

Post by via Digitalmars-d
If only it supported comments...

Yes comments would be amazing...also non-quoted keynames. If
we just added those 2 things to the JSON parser I would be
happy:)

Why are comments and non quoted key names needed?

[ketmar via Digitalmars-d]

On Mon, 25 Aug 2014 19:26:59 +0000

Post by Gary Willoughby via Digitalmars-d
Why are comments and non quoted key names needed?

'cause people are not computers. let's think about people first.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/52c428fd/attachment.sig>

[Suliman via Digitalmars-d]

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!

[Jonathan M Davis via Digitalmars-d]

Post by via Digitalmars-d
If only it supported comments...

Yeah, that's what I hate about JSON. It's pretty good overall,
but that's a huge deficiency IMHO - and I'd very much like to be
able to put comments in my dub package files. So, in that
respect, ASON seems like a definite improvement. However, I am a
bit wary of creating a new file format. Maybe if it's good enough
and marketed well enough, it could challenge JSON, but at the
moment, it would just be for dub, which isn't so great.

The fact that it's backwards compatible with JSON would be useful
for avoiding breaking existing dub packages, and it does sound
like it's a better format, but the fact that it's just been
created for this makes me leery. And even if we were to push it
beyond dub and try and get it accepted more widely, it's new
enough that I question that it won't need to be adjusted after
further use, since it's rare that anything complicated is done
right the first time.

So, I'm not necessarily against the idea of using ASON, but I'm
not sure that it's a good idea either.

- Jonathan M Davis

[Jonathan Marler via Digitalmars-d]

Post by Jonathan M Davis via Digitalmars-d

Post by via Digitalmars-d
If only it supported comments...

Yeah, that's what I hate about JSON. It's pretty good overall,
but that's a huge deficiency IMHO - and I'd very much like to
be able to put comments in my dub package files. So, in that
respect, ASON seems like a definite improvement. However, I am
a bit wary of creating a new file format. Maybe if it's good
enough and marketed well enough, it could challenge JSON, but
at the moment, it would just be for dub, which isn't so great.
The fact that it's backwards compatible with JSON would be
useful for avoiding breaking existing dub packages, and it does
sound like it's a better format, but the fact that it's just
been created for this makes me leery. And even if we were to
push it beyond dub and try and get it accepted more widely,
it's new enough that I question that it won't need to be
adjusted after further use, since it's rare that anything
complicated is done right the first time.
So, I'm not necessarily against the idea of using ASON, but I'm
not sure that it's a good idea either.
- Jonathan M Davis

Thanks for your reply Jonathan, I would have the same
reservations as you...I wouldn't want a languages exclusively
used for DUB. And you could be right that the language may
require some modifications since I just wrote it last Saturday.
On the other hand, new languages have to be introduced some where
right? Maybe if DUB started using it...other tools and software
would look into it?

[ponce via Digitalmars-d]

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.

[Kagamin via Digitalmars-d]

Post by Jonathan M Davis via Digitalmars-d
The fact that it's backwards compatible with JSON would be
useful for avoiding breaking existing dub packages, and it does
sound like it's a better format, but the fact that it's just
been created for this makes me leery.

Well, formats are created if existing formats are suboptimal.
JSON is not a general-purpose format, it was designed to be
locked on javascript parsers.

[Kagamin via Digitalmars-d]

On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis

Post by Jonathan M Davis via Digitalmars-d
The fact that it's backwards compatible with JSON would be
useful for avoiding breaking existing dub packages, and it
does sound like it's a better format, but the fact that it's
just been created for this makes me leery.

Well, formats are created if existing formats are suboptimal.
JSON is not a general-purpose format, it was designed to be
locked on javascript parsers.

If we want a popular markup language at some expense to save
people from learning new language, it should be XML - it's more
popular, than anything else.

[Sönke Ludwig via Digitalmars-d]

The fact that it's backwards compatible with JSON would be useful for
avoiding breaking existing dub packages, and it does sound like it's
a better format, but the fact that it's just been created for this
makes me leery.

Well, formats are created if existing formats are suboptimal. JSON is
not a general-purpose format, it was designed to be locked on
javascript parsers.

If we want a popular markup language at some expense to save people from
learning new language, it should be XML - it's more popular, than
anything else.

XML may pass the popularity test, but utterly fails at providing a more
concise and usable experience. As far as I'm concerned, it's about
finding the most "usable" language among those that are *decently* popular.

[Russel Winder via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d

The fact that it's backwards compatible with JSON would be useful for
avoiding breaking existing dub packages, and it does sound like it's
a better format, but the fact that it's just been created for this
makes me leery.

Well, formats are created if existing formats are suboptimal. JSON is
not a general-purpose format, it was designed to be locked on
javascript parsers.

If we want a popular markup language at some expense to save people from
learning new language, it should be XML - it's more popular, than
anything else.

XML may pass the popularity test, but utterly fails at providing a more
concise and usable experience. As far as I'm concerned, it's about
finding the most "usable" language among those that are *decently* popular.

XML has clearly failed as a build specification language. I offer you
Ant and Maven as evidence for the persecution of people who inflict XML
as a user written file format.

Clearly I am biased, but I like internal DSLs on dynamic languages for
build specification.
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/500e38d4/attachment.sig>

[Jonathan Marler via Digitalmars-d]

Post by Russel Winder via Digitalmars-d
Clearly I am biased, but I like internal DSLs on dynamic
languages for
build specification.

What are DSLs? Link?

[Russel Winder via Digitalmars-d]

On Tue, 2014-08-26 at 17:25 +0000, Jonathan Marler via Digitalmars-d

Post by Jonathan Marler via Digitalmars-d

Post by Russel Winder via Digitalmars-d
Clearly I am biased, but I like internal DSLs on dynamic
languages for
build specification.

What are DSLs? Link?

Technically it is a Domain Specific Language, but the whole thing is
really complicated since anyone who writes any functions or classes is
creating a DSL – it is really just the notion of creating abstraction:
tokens forming a language of discourse.

Internal vs external DSL: internal means a language constructed using
the symbols of the base language and not requiring a compiler, cf.
Boost.Spirit, anything written in a dynamic language. External DSL are
those requiring some form of compilation, cf. Make. Basically internal
DSL scripts are executed whereas external DSL scripts must be parsed.

In the context, Python can support an internal DSL for build, cf. SCons,
Waf. Groovy can support an internal DSL for build, cf. Gant, Gradle.

http://en.wikipedia.org/wiki/Domain-specific_language is not entirely
wrong ;-)
--
Russel.
=============================================================================
Dr Russel Winder t: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/f0178cfb/attachment.sig>

[bearophile via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
What are DSLs? Link?

http://en.wikipedia.org/wiki/Domain-specific_language

Bye,
bearophile

[Sönke Ludwig via Digitalmars-d]

The fact that it's backwards compatible with JSON would be useful for
avoiding breaking existing dub packages, and it does sound like it's
a better format, but the fact that it's just been created for this
makes me leery.

Well, formats are created if existing formats are suboptimal. JSON is
not a general-purpose format, it was designed to be locked on
javascript parsers.

If we want a popular markup language at some expense to save people from
learning new language, it should be XML - it's more popular, than
anything else.

XML may pass the popularity test, but utterly fails at providing a more
concise and usable experience. As far as I'm concerned, it's about
finding the most "usable" language among those that are *decently* popular.

[eles via Digitalmars-d]

Post by Jonathan M Davis via Digitalmars-d
The fact that it's backwards compatible with JSON would be
useful for avoiding breaking existing dub packages, and it does

That's not a tragedy. For a while, dub could maintain the ability
to read, even write the JSON format, and even to read .json and
write .sdl, de facto converting.

[Sönke Ludwig via Digitalmars-d]

The fact that it's backwards compatible with JSON would be useful for
avoiding breaking existing dub packages, and it does

That's not a tragedy. For a while, dub could maintain the ability to
read, even write the JSON format, and even to read .json and write .sdl,
de facto converting.

It will *always* continue to support JSON. There are absolutely no plans
to remove support. The plan is just to support an additional alternative
format that is better suited for human editors.

[eles via Digitalmars-d]

On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis

additional alternative format

SDL or D

[Nick Sabalausky via Digitalmars-d]

Post by eles via Digitalmars-d

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.

[eles via Digitalmars-d]

On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d

On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M Davis

On Monday, 25 August 2014 at 18:31:42 UTC, Marc SchÃŒtz

D's an interesting option but it utterly fails the KISS test.

Because there is no std.make or std.build or std.scons or
std.cmake module to help with that.

Post by Nick Sabalausky via Digitalmars-d
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.

But we could imagine a declarative layer in/over D or a module
directed at it. You know, one language to rule them all
(including declarative languages, just as the functional ones...).

Post by Nick Sabalausky via Digitalmars-d
And then there's meta-mess of needing the right compiler
version to properly handle a given package. Blech.

C'mon. This is because D is still running after its own tail. I
mean, keeps evolving ans is unstable. I bet things will very much
improve sooner than you think and that D frontend will play a
role.

[Nick Sabalausky via Digitalmars-d]

Post by Nick Sabalausky via Digitalmars-d
D's an interesting option but it utterly fails the KISS test.

Because there is no std.make or std.build or std.scons or std.cmake
module to help with that.

Post by Nick Sabalausky via Digitalmars-d
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.
But we could imagine a declarative layer in/over D or a module directed
at it. You know, one language to rule them all (including declarative
languages, just as the functional ones...).

Post by Nick Sabalausky via Digitalmars-d
And then there's meta-mess of needing the right compiler version to
properly handle a given package. Blech.

C'mon. This is because D is still running after its own tail. I mean,
keeps evolving ans is unstable. I bet things will very much improve
sooner than you think and that D frontend will play a role.

All reasonable points, but it still seems like swatting a fly with a
bazooka. ;)

[eles via Digitalmars-d]

On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d

Post by eles via Digitalmars-d
On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky

On Tuesday, 26 August 2014 at 13:55:13 UTC, Sönke Ludwig

On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M

All reasonable points, but it still seems like swatting a fly
with a bazooka. ;)

Well, you need a sharp eye and a sure hand. But otherwise, the
sole problem is if the fly is on someone's nose...

[Sönke Ludwig via Digitalmars-d]

Post by Nick Sabalausky via Digitalmars-d
All reasonable points, but it still seems like swatting a fly with a
bazooka. ;)

Well, you need a sharp eye and a sure hand. But otherwise, the sole
problem is if the fly is on someone's nose...

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

[eles via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d

Post by eles via Digitalmars-d
On Wednesday, 27 August 2014 at 05:47:37 UTC, Nick Sabalausky

Post by eles via Digitalmars-d
On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick

On Monday, 25 August 2014 at 19:35:09 UTC, Jonathan M

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

[Sönke Ludwig via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d
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

[eles via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d
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...

[Jacob Carlborg via Digitalmars-d]

But we could imagine a declarative layer in/over D or a module directed
at it. You know, one language to rule them all (including declarative
languages, just as the functional ones...).

You could probably come quite far with UDA's or similar.

[Wyatt via Digitalmars-d]

Post by eles via Digitalmars-d
On Wednesday, 27 August 2014 at 01:40:41 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d
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

[Sönke Ludwig via Digitalmars-d]

The fact that it's backwards compatible with JSON would be useful for
avoiding breaking existing dub packages, and it does

That's not a tragedy. For a while, dub could maintain the ability to
read, even write the JSON format, and even to read .json and write .sdl,
de facto converting.

It will *always* continue to support JSON. There are absolutely no plans
to remove support. The plan is just to support an additional alternative
format that is better suited for human editors.

[Jonathan Marler via Digitalmars-d]

Please read the entire post when you reply.

Post by Gary Willoughby via Digitalmars-d
I kind of get the feeling you're trying to push dub to use ASON.

Yes, in fact I explicitly stated that was my intention.

Post by Gary Willoughby via Digitalmars-d
My first reaction is, please don't invent yet another markup
language for developers to learn. Especially as this new
language is only relevant to dub.

That would have also been my first reaction. However, instead of
immediately dismissing the idea, it would be more productive to
state why you think the language is not a good fit, or why you
think SDL will do just fine. I explained why I think ASON would
be a better fit than SDL, do you have a counter-argument?

Post by Gary Willoughby via Digitalmars-d
Honestly it would seriously make me not want to use dub. Just
pick one of the existing ones, Yaml, Json, SDL (i've never
heard of this one.) and stick with it. All other package
managers seem to do just fine. Don't fix what isn't broken.

It would make you not want to use DUB? Could you please explain
why? If we used ASON you wouldn't have to change anything, you
could just continue to use regular JSON since it is already valid
ASON.

Post by Gary Willoughby via Digitalmars-d
Seriously though are you also willing to break all existing
dub.json files? That's 317 (http://code.dlang.org/ as of today)
packages this change is going to mess with. Are you really
going to do that? Just as things are starting to take off?

No, I wouldn't be willing to break anything. That's why I like
ASON, it doesn't break anything. Please read the post before you
reply next time.

Post by Gary Willoughby via Digitalmars-d
I'm in favour of just sticking to plain, normal old Json.
Everyone knows it, everyone understands it and everything else
does just fine using it.

That's fine, if we used ASON you could just continue to use plain
old JSON.

[Gary Willoughby via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
That would have also been my first reaction. However, instead
of immediately dismissing the idea, it would be more productive
to state why you think the language is not a good fit, or why
you think SDL will do just fine. I explained why I think ASON
would be a better fit than SDL, do you have a counter-argument?

Yes i do, it's simple, we don't need yet another markup language.

Post by Jonathan Marler via Digitalmars-d
It would make you not want to use DUB? Could you please explain
why?

Because learning a markup language tied exclusively to dub means
more work to use it. It means i have to learn yet another markup
language to package my code for others. Please answer why should
i bother?

Post by Jonathan Marler via Digitalmars-d
No, I wouldn't be willing to break anything. That's why I like
ASON, it doesn't break anything. Please read the post before
you reply next time.

I have read it and i don't agree with inventing yet another
markup language.

Post by Jonathan Marler via Digitalmars-d
That's fine, if we used ASON you could just continue to use
plain old JSON.

If that's the case why do we need ASON?

[Jonathan Marler via Digitalmars-d]

On Monday, 25 August 2014 at 18:40:02 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
That would have also been my first reaction. However, instead
of immediately dismissing the idea, it would be more
productive to state why you think the language is not a good
fit, or why you think SDL will do just fine. I explained why I
think ASON would be a better fit than SDL, do you have a
counter-argument?

Yes i do, it's simple, we don't need yet another markup
language.

You say "It's simple". How do you define simple...is ASON not
simple? I included the full grammar, it doesn't seem very
complex to me. Also you say, "we don't need another markup
language". That's what I was asking you to explain. The reason
we are looking into new languages is because of the list of
grievances we have with JSON (see the original post). Are you
saying that people's problems with JSON are invalid? Also,
what's wrong with new languages? If you have a problem with new
languages, what are you doing here on the D forum? Sounds like
C++ is a better fit for you.

Post by Jonathan Marler via Digitalmars-d
It would make you not want to use DUB? Could you please
explain why?

Because learning a markup language tied exclusively to dub
means more work to use it. It means i have to learn yet another
markup language to package my code for others. Please answer
why should i bother?

Well I just invented ASON last saturday so I don't know how
people will react to it. If DUB ends up using it I hope it isn't
exclusively used with DUB. I plan on introducing it at my work (I
work at HP) so we may start using it here. Also, is ASON really
that hard to learn? Here's my full tutorial on moving from JSON
to ASON:

1. Comments are supported...yay!
2. No need to quote strings if you don't want to.
3. No need for colons or commas if you don't want them.

There's a couple more features you can use like SingularNames and
Nameless fields but don't worry about those, those features come
with the advanced course that takes alot longer. Don't go there
unless you're willing to give up 5 minutes of your day.

I have read it and i don't agree with inventing yet another
markup language.

You still haven't explained why inventing new languages is bad.
If we had it your way we'd still be using assembly language.
Just because computer languages have been around for a while
doesn't mean they still can't be improved. D is a perfect
example of that. Instead of just writing things that you assume
are always correct, take the time to look at the situation and
provide useful insight as to why you think this particular
language is not a good fit.

Post by Jonathan Marler via Digitalmars-d
That's fine, if we used ASON you could just continue to use
plain old JSON.

If that's the case why do we need ASON?

Please see the original list of JSON grievances. I would say the
main one is COMMENTS.

[Idan Arye via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
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
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.

[Jonathan Marler via Digitalmars-d]

Post by Idan Arye via Digitalmars-d
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...

Post by Idan Arye via Digitalmars-d
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).

Post by Idan Arye via Digitalmars-d
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.

Post by Idan Arye via Digitalmars-d
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.

[Idan Arye via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d

Post by Idan Arye via Digitalmars-d
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.

Post by Jonathan Marler via Digitalmars-d

Post by Idan Arye via Digitalmars-d
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.

[Jonathan Marler via Digitalmars-d]

On Monday, 25 August 2014 at 23:00:59 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d

Post by Idan Arye via Digitalmars-d
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.

Post by Jonathan Marler via Digitalmars-d

Post by Idan Arye via Digitalmars-d
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.

[Nick Sabalausky via Digitalmars-d]

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.

[Sönke Ludwig via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
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
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.

[Nick Sabalausky via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
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
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.

[Idan Arye via Digitalmars-d]

On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d

On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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
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.

`dub describe` does not give you a normalized version of
"dub.json". It gives you something else:

$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined -
expected string.

Sure, the data to build a new "dub.json" is in there - after all,
all the data DUB can provide is in there. But that's the problem
- *all* the data DUB can provide is in there. That includes data
from downloaded dependencies, system data, (possibly) local
configuration data and anything can be added in the future.
That's the point of `dub describe` - query for anything DUB can
tell you and let the user pick what they need.

Even if the result of `dub describe` were valid for "dub.json",
you wouldn't want to put all that data in the project's
build-file! You want to be able to put "dub.json" under source
control and for that it must only contain information about the
project - not about the specific configuration of the machine of
the last developer who happened to run `dub describe` and
overwrite "dub.json".

`dub describe` is perfect for automated tools that want to query
DUB, but it's not a solution for tools that need to modify it.

[Nick Sabalausky via Digitalmars-d]

Post by Nick Sabalausky via Digitalmars-d

Post by Jonathan Marler via Digitalmars-d
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
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.

`dub describe` does not give you a normalized version of "dub.json". It
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined - expected
string.

Ok, I see now. Yea, that could be improved. Luckily it shouldn't be a
difficult feature to add, though.

`dub describe` is perfect for automated tools that want to query DUB,
but it's not a solution for tools that need to modify it.

Well, it would probably work, it just wouldn't be an ideal solution. But
again, that "dub normalize" you suggest (or "dub describe --normalize"
or something) should do the trick. So it doesn't appear to be a
deal-breaker for supporting another language, it's just an additional
TODO for dub.

[Idan Arye via Digitalmars-d]

On Wednesday, 27 August 2014 at 19:06:29 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d

Post by Idan Arye via Digitalmars-d
On Wednesday, 27 August 2014 at 01:51:54 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d

On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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
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.

`dub describe` does not give you a normalized version of
"dub.json". It
$ dub init
Successfully created an empty project in '/tmp/dub-test'.
$ dub describe > dub.json.new
$ mv dub.json.new dub.json
$ dub describe
Error executing command describe: Got .name of type undefined
- expected
string.

Ok, I see now. Yea, that could be improved. Luckily it
shouldn't be a difficult feature to add, though.

Post by Idan Arye via Digitalmars-d
`dub describe` is perfect for automated tools that want to
query DUB,
but it's not a solution for tools that need to modify it.

Well, it would probably work, it just wouldn't be an ideal
solution. But again, that "dub normalize" you suggest (or "dub
describe --normalize" or something) should do the trick. So it
doesn't appear to be a deal-breaker for supporting another
language, it's just an additional TODO for dub.

I don't like `dub describe --normalize` - it implies that the
regular `dub describe` is in some non-normalize format and adding
this flag will normalize the output. If you want to add
normalization as a `dub describe` flag, I'd prefer something like
`dub describe --buildfile-only`

[Nick Sabalausky via Digitalmars-d]

I don't like `dub describe --normalize` - it implies that the regular
`dub describe` is in some non-normalize format and adding this flag will
normalize the output. If you want to add normalization as a `dub
describe` flag, I'd prefer something like `dub describe --buildfile-only`

Yea, that's better. I just meant "Maybe a flag for 'describe' rather
than a separate dub command." and didn't feel like coming up with an
alternative name. :)

[Kagamin via Digitalmars-d]

Post by Idan Arye via Digitalmars-d
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.

[Weaseldog via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
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
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.

[Jonathan Marler via Digitalmars-d]

Post by Weaseldog via Digitalmars-d

Post by Jonathan Marler via Digitalmars-d
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.
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.

[Jeremy Powers via Digitalmars-d]

On Mon, Aug 25, 2014 at 4:08 PM, Jonathan Marler via Digitalmars-d <

Post by Jonathan Marler via Digitalmars-d
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140825/654218df/attachment.html>

[Jonathan Marler via Digitalmars-d]

Post by Jeremy Powers via Digitalmars-d
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)

[Dicebot via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
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
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/

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

[ponce via Digitalmars-d]

On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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.
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.

[eles via Digitalmars-d]

Post by ponce via Digitalmars-d

On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler

- SDL is _whitespace sensitive_

I don't like this.

Post by ponce via Digitalmars-d
- 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.

Post by ponce via Digitalmars-d
- 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...

[ketmar via Digitalmars-d]

On Tue, 26 Aug 2014 08:53:44 +0000

Post by eles via Digitalmars-d

Post by ponce via Digitalmars-d
- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/ea1dc847/attachment.sig>

[eles via Digitalmars-d]

On Tuesday, 26 August 2014 at 09:12:36 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Tue, 26 Aug 2014 08:53:44 +0000
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?

[ketmar via Digitalmars-d]

On Tue, 26 Aug 2014 09:32:09 +0000

Post by eles via Digitalmars-d
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/653c6091/attachment.sig>

[Sönke Ludwig via Digitalmars-d]

Post by ketmar via Digitalmars-d
On Tue, 26 Aug 2014 09:32:09 +0000

Post by eles via Digitalmars-d
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
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.

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.

[ketmar via Digitalmars-d]

On Tue, 26 Aug 2014 12:20:55 +0200

Post by Sönke Ludwig via Digitalmars-d
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.

most widely-used json parsers supports that three features anyway, i
believe, so it's almost safe to just add 'em.

yes, we can have other backends -- xml, ason, sdl, anything. but i
can't see any sane reasons to add such backends. they will lead to code
bloating, more testing and will just confuse end-users ("oh, which
backend i should use? why there are so many?").
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/02e34ada/attachment.sig>

[eles via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d

Post by ketmar via Digitalmars-d
On Tue, 26 Aug 2014 09:32:09 +0000

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/

[Jeremy Powers via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d
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.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/0a0c22d9/attachment.html>

[via Digitalmars-d]

On Tuesday, 26 August 2014 at 18:35:55 UTC, Jeremy Powers via

Post by Jeremy Powers via Digitalmars-d

Post by Sönke Ludwig via Digitalmars-d
I agree. Those would be the points with most impacts.
However, the

Post by Sönke Ludwig via Digitalmars-d
outcome would be quite far away from standard JSON, so we
would really be
talking about something like ASON or SDL already.

http://json5.org/

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.

[Idan Arye via Digitalmars-d]

Post by via Digitalmars-d
On Tuesday, 26 August 2014 at 18:35:55 UTC, Jeremy Powers via

Post by Jeremy Powers via Digitalmars-d

Post by Sönke Ludwig via Digitalmars-d
I agree. Those would be the points with most impacts.
However, the

Post by Sönke Ludwig via Digitalmars-d
outcome would be quite far away from standard JSON, so we
would really be
talking about something like ASON or SDL already.

http://json5.org/

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.

[eles via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d

Post by ketmar via Digitalmars-d
On Tue, 26 Aug 2014 09:32:09 +0000

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.

Anyway, if moving away from JSON is a must, and SDL will be good
enough, the I would vote for it.

[eles via Digitalmars-d]

On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Tue, 26 Aug 2014 09:32:09 +0000

Post by eles via Digitalmars-d
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
1. comments, both '//' and '/* */.

Not exactly that, but look here two approaches for introducing
comments in standard JSON:

1: a convention

http://stackoverflow.com/a/244858


2: a hack

http://fadefade.com/json-comments.html

[ketmar via Digitalmars-d]

On Tue, 26 Aug 2014 10:36:14 +0000

Post by eles via Digitalmars-d
Not exactly that, but look here two approaches for introducing

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.

i'm still sure that JSON specs are needlessly strict in some areas, and
specs should include comments from the start...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/1fd9e646/attachment.sig>

[via Digitalmars-d]

Post by eles via Digitalmars-d
On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Tue, 26 Aug 2014 09:32:09 +0000

Post by eles via Digitalmars-d
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
1. comments, both '//' and '/* */.

Not exactly that, but look here two approaches for introducing
1: a convention
http://stackoverflow.com/a/244858
2: a hack
http://fadefade.com/json-comments.html

These are mostly useful for documentation comments, but not so
much for disabling parts of the definitions temporarily, which
would be my primary use case.

[eles via Digitalmars-d]

Post by via Digitalmars-d

Post by eles via Digitalmars-d
On Tuesday, 26 August 2014 at 10:00:29 UTC, ketmar via

Post by ketmar via Digitalmars-d
On Tue, 26 Aug 2014 09:32:09 +0000

These are mostly useful for documentation comments, but not so
much for disabling parts of the definitions temporarily, which
would be my primary use case.

Yes, I missed that. Good point.

[Marco Leise via Digitalmars-d]

Am Tue, 26 Aug 2014 13:47:05 +0300

Post by ketmar via Digitalmars-d
On Tue, 26 Aug 2014 10:36:14 +0000

Post by eles via Digitalmars-d
Not exactly that, but look here two approaches for introducing

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.

[Nick Sabalausky via Digitalmars-d]

Post by eles via Digitalmars-d

Post by ponce via Digitalmars-d
- 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 ;)

Post by eles via Digitalmars-d

Post by ponce via Digitalmars-d
- 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.

Post by eles via Digitalmars-d

Post by ponce via Digitalmars-d
- 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.

[Kagamin via Digitalmars-d]

On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d
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 ;)

That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line
continuations.

Post by Nick Sabalausky via Digitalmars-d

Post by eles via Digitalmars-d

Post by ponce via Digitalmars-d
- 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.

What's wrong with XML? I work with it daily and see no problem.
The less syntax a language has, the worse it scales, and if it
doesn't scale, its adoption creates a technical debt. 100 lines
with 3 levels of nesting and JSON becomes hard to follow and TOML
becomes simply unmanageable.

[Sönke Ludwig via Digitalmars-d]

Post by Kagamin via Digitalmars-d

Post by Nick Sabalausky via Digitalmars-d
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 ;)

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?

Post by Kagamin via Digitalmars-d

Post by Nick Sabalausky via Digitalmars-d

Post by eles via Digitalmars-d

Post by ponce via Digitalmars-d
- 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.

What's wrong with XML? I work with it daily and see no problem. The less
syntax a language has, the worse it scales, and if it doesn't scale, its
adoption creates a technical debt. 100 lines with 3 levels of nesting
and JSON becomes hard to follow and TOML becomes simply unmanageable.

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.

[eles via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d

Post by Kagamin via Digitalmars-d
On Wednesday, 27 August 2014 at 02:24:46 UTC, Nick Sabalausky

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/

[Sönke Ludwig via Digitalmars-d]

Post by eles via Digitalmars-d

Post by Sönke Ludwig via Digitalmars-d
The reason to search for an additional format is to make it more
convenient and readable for human interaction.

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.

[Kagamin via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d

Post by Kagamin via Digitalmars-d
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.

Post by Sönke Ludwig via Digitalmars-d
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!

[Jonathan Marler via Digitalmars-d]

On Wednesday, 27 August 2014 at 09:27:03 UTC, Sönke Ludwig

Post by Sönke Ludwig via Digitalmars-d

Post by Kagamin via Digitalmars-d
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.

Post by Sönke Ludwig via Digitalmars-d
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.
"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>.

[Nick Sabalausky via Digitalmars-d]

Post by Sönke Ludwig via Digitalmars-d

Post by Kagamin via Digitalmars-d

Post by Nick Sabalausky via Digitalmars-d
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 ;)

That's justified, because SDL fails to not surprise. Curly brace
syntaxes are not line-delimited not requires backslash line
continuations.

Yea, I'll grant it *is* somewhat of a blemish in SDL's design. But I
don't think it's a critical one.

Besides, this thread's (dare I say "bikeshedded"?) quest for an ideal
data language seems doomed from the start: If we try to avoid the less
common ones, and avoid inventing our own (which I think we have good
reason to avoid), then everything left *does* have imperfections.

Therefore, I think the main critera we should be looking at here, for
any of the possibilities, isn't "Does this language have flaws?" but
rather "Is this language *good enough* to be supported by DUB as a JSON
alternative?"

Post by Sönke Ludwig via Digitalmars-d
Like JavaScript for example?

Heh, there is that.

Post by Sönke Ludwig via Digitalmars-d

Post by Kagamin via Digitalmars-d
What's wrong with XML? I work with it daily and see no problem. The less
syntax a language has, the worse it scales, and if it doesn't scale, its
adoption creates a technical debt. 100 lines with 3 levels of nesting
and JSON becomes hard to follow and TOML becomes simply unmanageable.

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.

That's a big one. *The* big one in my mind.

Additionally, despite XML's simplistic appearance, some of the details
about it get disturbingly over-engineered. Heck, take a look at W3C's
docs on it: for something that's *supposed* to be as simple as:

<tag1>
<tag2 attr="value">blah</tag2>
<tag3 />
</tag1>

For something that *appears* to be that simple, it's formal reality is
horrifically complicated.

Besides, there's nothing stopping a good editor from taking this:

{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
}
}

And adding helper visuals (not part of the actual document) to display
it as this:

{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
} <i>"tag1"</i>
} <i>{root}</i>

(The <i></i> wouldn't be displayed, I just put them there to indicate
the text inside would be visually distinguished so that the user finds
it obvious it's not actually part of the document. Can't really emulate
that in a NG post.)

I don't know why no editors ever do that.

[Jeremy Powers via Digitalmars-d]

On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via Digitalmars-d <

Therefore, I think the main critera we should be looking at here, for any
of the possibilities, isn't "Does this language have flaws?" but rather "Is
this language *good enough* to be supported by DUB as a JSON alternative?"

The 'alternative' bit is the kicker. Personally, I don't believe DUB can
succeed at having multiple supported config languages - one or the other
will win out over time, and users will diverge. So no language would meet
that bar (in my opinion).

Mostly we are talking about JSON+stuff as an additional language... so can
it be reframed as 'additional features you can use in your dub config file,
that aren't strict JSON'?

Framing things this way, you could (for example) switch DUB entirely over
to ASON, and avoid the 'switching to a new language' arguments. DUB takes
JSON, DUB also accepts not-strictly-JSON syntax like comments, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140827/5b3ecf89/attachment.html>

[Kagamin via Digitalmars-d]

On Wednesday, 27 August 2014 at 19:30:35 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d
Besides, there's nothing stopping a good editor from taking
{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
}
}
And adding helper visuals (not part of the actual document) to
{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
} <i>"tag1"</i>
} <i>{root}</i>
(The <i></i> wouldn't be displayed, I just put them there to
indicate the text inside would be visually distinguished so
that the user finds it obvious it's not actually part of the
document. Can't really emulate that in a NG post.)

You just acknowledged succinct languages don't scale, and the
only way to make them scale is to turn them into syntactical
equivalent of XML with closing tags. And even then more verbose
than XML itself. So what's a difference from XML if good config
language still must have XML syntax?

Post by Nick Sabalausky via Digitalmars-d
I don't know why no editors ever do that.

The editors show only what's written and written is JSON, not
JSON++.

[Nick Sabalausky via Digitalmars-d]

Post by Kagamin via Digitalmars-d

Post by Nick Sabalausky via Digitalmars-d
{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
}
}
And adding helper visuals (not part of the actual document) to display
{
"tag1" : {
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
...blah, blah, blah, blah...
} <i>"tag1"</i>
} <i>{root}</i>
(The <i></i> wouldn't be displayed, I just put them there to indicate
the text inside would be visually distinguished so that the user finds
it obvious it's not actually part of the document. Can't really
emulate that in a NG post.)

You just acknowledged succinct languages don't scale,

No, I've only acknowledged that they don't exhibit *perfect* scaling.
They certainly still scale. And they can scale even better with a little
editor help.

Post by Kagamin via Digitalmars-d
and the only way
to make them scale is to turn them into syntactical equivalent of XML
with closing tags. And even then more verbose than XML itself. So what's
a difference from XML if good config language still must have XML syntax?

The differences (off the top of my head, there may be more):

- Nobody has to actually write the closing
- Nobody had to keep the opening/closing in sync
- The closing takes up zero bytes
- Nobody has to actually look at the closing if they want to reduce the
visual clutter: Ie, viewing it is an optional thing.

Post by Kagamin via Digitalmars-d

Post by Nick Sabalausky via Digitalmars-d
I don't know why no editors ever do that.

The editors show only what's written and written is JSON, not JSON++.

My editor shows all sorts of stuff that ain't written. Line numbers,
80-col mark, visible whitespace/EOLs, indent guides, a horizontal line
to denote folded code sections, etc. You're not going to split hairs and
claim those are fundamentally/meaningfully different from what I'm
suggesting are you?

[via Digitalmars-d]

On Thursday, 28 August 2014 at 19:47:13 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d

Post by Kagamin via Digitalmars-d
and the only way
to make them scale is to turn them into syntactical equivalent of XML
with closing tags. And even then more verbose than XML itself. So what's
a difference from XML if good config language still must have
XML syntax?

- Nobody has to actually write the closing
- Nobody had to keep the opening/closing in sync
- The closing takes up zero bytes
- Nobody has to actually look at the closing if they want to
reduce the visual clutter: Ie, viewing it is an optional thing.

So it has no advantage over using a grammar-based XML editor,
just less flexible and more clumsy
 Sounds like the wrong
trade-off.

(tags don't take much space when the file is compressed)

[Dicebot via Digitalmars-d]

On Friday, 29 August 2014 at 02:10:47 UTC, Jeremy Powers via

Post by Jeremy Powers via Digitalmars-d
On Wed, Aug 27, 2014 at 12:30 PM, Nick Sabalausky via
Digitalmars-d <

Post by Nick Sabalausky via Digitalmars-d
Therefore, I think the main critera we should be looking at
here, for any
of the possibilities, isn't "Does this language have flaws?"
but rather "Is
this language *good enough* to be supported by DUB as a JSON
alternative?"

The 'alternative' bit is the kicker. Personally, I don't
believe DUB can
succeed at having multiple supported config languages - one or
the other
will win out over time, and users will diverge. So no language
would meet
that bar (in my opinion).

I can totally see JSON format being used mostly by the tools and
new one written by actual developers - everyone gets its niche.

[Dicebot via Digitalmars-d]

Post by ponce via Digitalmars-d

On Monday, 25 August 2014 at 16:40:10 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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.
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.

[Dicebot via Digitalmars-d]

Post by Dicebot via Digitalmars-d
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

[Nick Sabalausky via Digitalmars-d]

Post by ponce via Digitalmars-d
- 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.

[Nick Sabalausky via Digitalmars-d]

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

[Russel Winder via Digitalmars-d]

On Mon, 2014-08-25 at 16:40 +0000, Jonathan Marler via Digitalmars-d

Post by Jonathan Marler via Digitalmars-d
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
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: [phone] voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: [phone] xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140826/04dd76d0/attachment-0001.sig>

[Sönke Ludwig via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
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
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

[Jonathan Marler via Digitalmars-d]

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.

[Gary Willoughby via Digitalmars-d]

On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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

[eles via Digitalmars-d]

On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby

Post by Gary Willoughby via Digitalmars-d
On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler
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.

[Jonathan Marler via Digitalmars-d]

Post by eles via Digitalmars-d
On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby

Post by Gary Willoughby via Digitalmars-d
On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler
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.

This is why dforums needs a like button:)

[Jonathan Marler via Digitalmars-d]

On Wednesday, 27 August 2014 at 12:25:43 UTC, Gary Willoughby

Post by Gary Willoughby via Digitalmars-d
On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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

Post by Gary Willoughby via Digitalmars-d
On Wednesday, 27 August 2014 at 10:51:28 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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.

[Gary Willoughby via Digitalmars-d]

On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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.

I'm not necessarily arguing that Json is great or flexible. I'm
arguing, well maybe arguing is a strong word, i'm positing that
something more complicated than Json isn't really needed at this
time.

I understand the argument that it would be nice for
human-friendly constructs to be present in the dub file but is
this really a problem dub is facing at the minute? Are lots of
devs venting their spleens over not being able to include
comments, heredoc strings and such in dub files? The dub registry
is gaining traction lets not throw an obstacle in the road now.

Also inventing a Frankenstein format that is both a superset of
Json and SDL just sounds horrible and just sounds wrong. It's
just too much. Your effort would be better directed to something
which is an immediate problem. Not re-inventing this particular
wheel.

Sonke has said Json will always be an option in dub. Which is
fantastic because now that dub has reached an official level as
the de-facto package manager we need to embrace stability and
stop this needless change which has been plaguing D forever.

I honestly think Ason should be abandoned as an unneeded solution
looking for a problem and something more stable and recognised
like Yaml or XML, etc. implemented in future *if needed* and
actually if requested by dub's users.

[Jonathan Marler via Digitalmars-d]

On Wednesday, 27 August 2014 at 15:27:25 UTC, Gary Willoughby

Post by Gary Willoughby via Digitalmars-d
On Wednesday, 27 August 2014 at 15:07:22 UTC, Jonathan Marler

Post by Jonathan Marler via Digitalmars-d
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.

I'm not necessarily arguing that Json is great or flexible. I'm
arguing, well maybe arguing is a strong word, i'm positing that
something more complicated than Json isn't really needed at
this time.
I understand the argument that it would be nice for
human-friendly constructs to be present in the dub file but is
this really a problem dub is facing at the minute?

Yes. dub is most definitely facing this problem at this minute.

Post by Gary Willoughby via Digitalmars-d
Are lots of devs venting their spleens over not being able to
include comments, heredoc strings and such in dub files? The
dub registry is gaining traction lets not throw an obstacle in
the road now.

heredoc's is a new one, but comments/nesting/trailing
commas/unquoted strings, yes, most assuredly yes. Have you not
been reading people's concerns about JSON? How could you say that
people aren't complaining?

Post by Gary Willoughby via Digitalmars-d
Also inventing a Frankenstein format that is both a superset of
Json and SDL just sounds horrible and just sounds wrong. It's
just too much. Your effort would be better directed to
something which is an immediate problem. Not re-inventing this
particular wheel.

I most definitely wouldn't call ASON a "Frankenstein" format. I
didn't design ASON to be a superset of SDL, that's just how it
worked out. Just like YAML happens to be a superset of JSON.
Instead of saying it "sounds horrible and just sounds wrong", why
don't you look at the language spec and say what is wrong about
it. It's fine if you think we shouldn't use a new language but
even if no one ever uses it, it's helpful to know what features
people think are good/bad so we can all learn something.

Post by Gary Willoughby via Digitalmars-d
Sonke has said Json will always be an option in dub. Which is
fantastic because now that dub has reached an official level as
the de-facto package manager we need to embrace stability and
stop this needless change which has been plaguing D forever.

Yes, JSON will always be used to represent the package format on
the back-end. So it makes sense to allow users to use it on the
front-end if they wish. And again, adding a new format isn't a
"needless change", why do you think so many people have such
strong opinions about what format to use. You seem to be one of
the only ones that thinks adding a new format (or using "lenient
JSON") is a bad thing.

Post by Gary Willoughby via Digitalmars-d
I honestly think Ason should be abandoned as an unneeded
solution looking for a problem and something more stable and
recognised like Yaml or XML, etc. implemented in future *if
needed* and actually if requested by dub's users.

You seem to be stuck on the idea that I think DUB should use
ASON. I created this thread so I could learn from other people
what they think about this format and others. Even though you
haven't added anything helpful, after reading other people's
posts I'm now leaning more towards SDl. My biggest complaint is
that it might be confusing for people to go between the SDL
version and the JSON version. However, Sonke thinks that he can
make a much more friendly package format with SDL's extra
features like tag values/attributes.

[Gary Willoughby via Digitalmars-d]

On Wednesday, 27 August 2014 at 15:57:41 UTC, Jonathan Marler

Even though you haven't added anything helpful...

If you don't want input, don't publicly ask for it. Just because
my input is not what you would deem helpful because it
contradicts your view does not mean it's of no value. I always
argue from a standpoint of zero change regarding anything to do
with D and always will do.

D and its tools are crying out for stability right now. Change
for change sake has seriously hurt D in the past.

Yes. dub is most definitely facing this problem at this minute.

Where? in this *one* thread?

[ketmar via Digitalmars-d]

On Wed, 27 Aug 2014 16:57:52 +0000

Post by Gary Willoughby via Digitalmars-d
D and its tools are crying out for stability right now.

there is D1. stable as a doornail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140827/52e6d560/attachment.sig>

[Nick Sabalausky via Digitalmars-d]

D and its tools are crying out for stability right now. Change for
change sake has seriously hurt D in the past.

It's also been a critical factor in it's success.

Double-edged sword, admittedly.

[Andrei Alexandrescu via Digitalmars-d]

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

Then perfection in personal finance is easy to achieve :o). -- Andrei

[Poyeyo via Digitalmars-d]

Post by Jonathan Marler via Digitalmars-d
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
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2263/

Wait, SDL is not Simple DirectMedia Layer ?

You broke my hope.