On 11/26/2015 11:08 PM, Sönke Ludwig wrote:
This looks like it's creeping towards inventing a new script programming language. Adding loops, switch statements, functions, etc., can't be far off. Before you get too far down this path, consider:Actually, no! Conditionals and loops are the only constructs - switch is a possibility, but basically nothing else. There will also never be variables, just constants. There is a definitive limit, namely when it becomes impossible to reason about the code in a generic way, without "executing" it, so in particular anything that would make it touring complete is a no-go - no recursion, no loop flow control statements, no goto. In fact, there are no "statements" at all, these are all purely declarative "directives".
I would say to that: "famous last words". As Exhibit A, I submit 'static if', which has been getting increasing pressure to augment with loops.
1. JSON has a superset programming language - Javascript - which has conventional syntax rather than the DEP4 proposal for odd syntax like if dub-version="<0.9.24" which I would strongly recommend against. And, we already have a Javascript engine written in D: https://github.com/DigitalMars/DMDScript 2. D itself can be used as a scripting language (when # is the first character in the source code). Having DUB use this might be quite interesting.On one hand that means that now you have to take care of security issues (holes in the scripting engine/compiler or DoS attacks of various sorts) when you want to use this on a server (code.dlang.org).
You have to deal with that even if just plain json or sdl. After all, the implementation of those formats could be susceptible to buffer overflow or DoS as well. But this is less likely with json, because you'd be using a well-used json parser rather than your own sdl parser that is only used for Dub. (Yes I saw later that you use it in some other projects, but does it see use outside of your own things?)
Javascript can only interact with its environment using the DOM. If Dub presented its own DOM to the js engine, there isn't much the js code can do other than go into an infinite loop, recursive overflow, or exploit a buffer overflow.
Once there are big numbers of packages, this could also mean that the hardware eventually needs to be upgraded when it would have done fine for a long time with a tiny declarative parser.
I would think these problems have all been solved with Javascript, since it is used so extensively. Javascript is also a lightweight scripting language.
On the other hand, it's not possible with a script to make general predictions of how a package would behave, for example the script could select a dependency based on some environment variable or a file that is only defined on the target system.
That goes back to restricting the DOM.
Finally, it's always possible to switch from declarative to script without loosing expressive power, but not necessarily the other way around.
True, but consider this. JSON is a subset of Javascript. That means you could add a subset of Javascript to JSON, i.e. just the if statements. You'll have a clear design for it, and a clear path for how to do further enhancements.
"With a standard json parser in Phobos, zip zap boom you're done. You don't have to design it, argue about it, build it, document it, debug it, test it, optimize it, explain it, deal with bug requests, deal with enhancement requests, deal with legacy compatibility, build a converter, build a gui tool for it, etc."Let's say this isn't really an argument anymore now that it has already been done,
The existence of the DEPs suggest otherwise, the number of posts in this thread suggest otherwise, the calls for a gui editor suggest otherwise, the customer "should I use json or sdl" makes for an ongoing support problem, no current means to convert between the two, etc.
but it wouldn't have been a strong argument anyway, because the SDLang parser is actually in use for other projects as well, so it has to be maintained anyway. There really is very little investment necessary development-wise, I think it took me maybe three to four hours total to implement it, including the support on code.dlang.org. Creating the sdlang-d library itself (by Nick Sabalausky) was of course a bigger task, as were the discussions and the design process.
The time for JSON was zero. You're a key developer here, and your time is very valuable. I can't tell you what to work on, but I can't be quiet about spending time on things with such marginal utility (and yes, I waste time, too). By using sdl, though, you're also spending other peoples' time, even if it's just "which format should I use for my project?" and then the D forum members have to advise them.
But apart from that, finding a format that a) allows (real) comments and b) has
less syntax noise was necessary in any case. Sure, JSON *works*, but it becomes
really unpleasant with more complicated files, and the whole {"comment": "..."}
approach is nothing but an ugly and highly inconvenient hack, both when writing
and when reading it.
I'm not accepting the "ugly and highly inconvenient hack" argument in the light of the DEP4 proposal for conditional syntax that I already commented on. And, as mentioned before, I use $(COMMENT ...) in Ddoc and it works out quite nicely, even though Ddoc has no syntax for comments.
And if comments were the only reason to use sdl, and a solid case was made for them vs my suggestion, I'd vastly prefer adding /**/ to the json support rather than switching to an apparently dead format.
And the fact is that no matter which other format we would have chosen (JSON with comments is also another language) we'd have these bikeshedding discussions.
Sticking with json would enable you to simply ignore it. But you've been pretty much forced to engage in this one.
