On Wed, 11 Sep 2013 11:04:37 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> As for long values, I've always disliked the fact that almost all formats provide a way to wrap them across multiple lines, but almost none of them let you indent the result nicely without also changing the value.  This is important for complex configuration formats that have nested groups of settings. In my format, the syntax is specifically catered for this use case, for example:
> 
> 	# This is a comment
> 	value1 = "This is a very long value \
> 	         \split across multiple \
> 	         \lines."
> 	value2 = "A short value"
> 
> 	module1 {
> 		# These values are in a nested scope, so they are
> 		# distinct from the settings above.
> 		value1 = "This is another long \
> 		         \value split across \
> 		         \multiple lines."
> 		value2 = "This is a value \
> 		         \with an embedded \   # a long value
> 		         \comment!"
> 	}
> 

SDL supports that sort of thing (except for the embedded comment,
which I agree would be kinda nice):

http://sdl.ikayzo.org/display/SDL/Language+Guide
See section "String Literals"

Your example would look like this :

# This is a comment
value1 "This is a very long value \
        split across multiple \
        lines."
value2 "A short value"

module1 {
	# These values are in a nested scope, so they are
	# distinct from the settings above.
	value1 "This is another long \
	        value split across \
	        multiple lines."
}

If you want the indentation *kept*, then use backquote strings (and omit the line continuation backslashes).

The embedded comments could be easily added, but that would take it into "non-standard behavior" territory. (I actually had to deliberately disallow it just to match the behavior of the reference implementation).

On Wed, 11 Sep 2013 13:06:05 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote:
> > On Wednesday, September 11, 2013 11:04:37 H. S. Teoh wrote:
> > > On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
> > > > On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
> > > > > Why not YAML? It's cleaner than JSON and is very widely known.
> > > > 
> > > > YAML is just plain evil. It doesn't ignore whitespace.
> > > 
> > > [...]
> > > 
> > > It's funny. I used to think Python is evil for the same reason,
> > 
> > Well, I hate that about python too, but what I _really_ hate about python is that it's dynamic. It shouldn't be possible to do things like change the type of a variable based on whether an if condition was true or not (or change the type of a variable at all for that matter).
> 
> Yeah, this is something oft touted as being 'convenient' and 'easy', but then in production code, you find yourself writing type checks anyway just to make sure what's passed in is what you expect. (And things blow up in horrible ways when some stray code passes in something with the wrong type.) Which defeats the purpose of having a dynamic language in the first place.
> 

My feelings on it exactly. I also found the implicit member declarations
and its inability to match software to the correct runtime (like Java
does) to be major problems, too:
https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really

> > > But I've never used YAML, so I can't say whether or not I'd like it.
> > 
> > JSON is a subset of YAML 1.2, so they're very similar. Probably the most obvious differences are that you don't need as many quotes in YAML, and whitespace matters. I've had to deal with it some at work, and I hope to never have to deal with it elsewhere.
> [...]
> 
> Wait, how can JSON be a subset of YAML if whitespace in YAML is significant, but it isn't in JSON?
> 

Whitespace is only sometimes significant in YAML. On the JSON constructs, it's not significant. On certain (all?) of the non-JSON YAML-specific things, then it's significant.

Am 11.09.2013 21:20, schrieb Jonathan M Davis:
>
> I don't know if it's quite ready for that or not, but I've started using it
> for most of my stuff. It feels kind of limited to me, and I'm inclined to think
> that it will need more advanced build configuration abilities in the future (it
> essentially does what rdmd does, whereas some projects will need something
> more along the lines of full-on make capabilities), but for basic stuff, it
> works just fine.
>

Do you have (a) concrete example(s) where things need to get more powerful?

I try to keep the surface as simple as possible while handling the complexity mostly in the background. But of course manual control is necessary in some places.

One thing that definitely needs some improvements is the build system (for example building dependencies separately and caching the resulting binaries for reuse and at some point performing proper incremental builds).

On Wed, 2013-09-11 at 15:17 -0400, Jonathan M Davis wrote: […]
> that it's dynamic. It shouldn't be possible to do things like change the type of a variable based on whether an if condition was true or not (or change the type of a variable at all for that matter). I use python at work when I need to use a scripting language, because it's the best option that I have there, but otherwise, I'd just use D.
[…]

The type of variables in Python do not change. Python is a strongly typed language. The type of all variables is pointer to object.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Wed, 11 Sep 2013 22:40:30 +0100
Russel Winder <russel@winder.org.uk> wrote:

> On Wed, 2013-09-11 at 15:17 -0400, Jonathan M Davis wrote: […]
> > that it's dynamic. It shouldn't be possible to do things like change the type of a variable based on whether an if condition was true or not (or change the type of a variable at all for that matter). I use python at work when I need to use a scripting language, because it's the best option that I have there, but otherwise, I'd just use D.
> […]
> 
> The type of variables in Python do not change. Python is a strongly typed language. The type of all variables is pointer to object.
> 

Technically, yes, but the *effect* is the same as:

int foo;
if(cond)
	foo = "Whee!! This is SOOOO useful for things
	*other* than generating bugs!";

On Wednesday, September 11, 2013 13:06:05 H. S. Teoh wrote:
> > JSON is a subset of YAML 1.2, so they're very similar. Probably the most obvious differences are that you don't need as many quotes in YAML, and whitespace matters. I've had to deal with it some at work, and I hope to never have to deal with it elsewhere.
> 
> [...]
> 
> Wait, how can JSON be a subset of YAML if whitespace in YAML is significant, but it isn't in JSON?

I don't know. Maybe there's an alternate syntax in YAML that uses braces like JSON and isn't whitespace-sensitive? I'm not enough of an expert on them to know all of the little details. You can read what little it says on wikipedia:

https://en.wikipedia.org/wiki/YAML#JSON

But I know that whitespace matters in YAML at least some of the time, and I've hated dealing with it.

- Jonathan M Davis

On Wed, Sep 11, 2013 at 05:11:38PM -0400, Nick Sabalausky wrote:
> On Wed, 11 Sep 2013 13:06:05 -0700
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> > On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote:
[...]
> > > Well, I hate that about python too, but what I _really_ hate about python is that it's dynamic. It shouldn't be possible to do things like change the type of a variable based on whether an if condition was true or not (or change the type of a variable at all for that matter).
> > 
> > Yeah, this is something oft touted as being 'convenient' and 'easy', but then in production code, you find yourself writing type checks anyway just to make sure what's passed in is what you expect. (And things blow up in horrible ways when some stray code passes in something with the wrong type.) Which defeats the purpose of having a dynamic language in the first place.
> > 
> 
> My feelings on it exactly. I also found the implicit member declarations
> and its inability to match software to the correct runtime (like Java
> does) to be major problems, too:
> https://semitwist.com/articles/article/view/why-i-hate-python-or-any-dynamic-language-really

Yeah I remember reading that. I haven't had Python blow up on me like that (yet), but I first ran into this problem while writing some JS code.

That was when I had to write some complex code to handle client-side dialogues (yeah, *those* ugly things), and, in an effort to prevent the code from becoming one long, winding spaghetti noodle, I decided to factor out common bits into functions -- you know, typical structured programming textbook exercise. Then things stopped working, and I couldn't figure out why. Eventually, after many hours of hair-tearing frustration, I found out that some stray code was passing in the wrong object to one of the functions.  But of course, the JS interpreter couldn't care less -- there's no type system for a type mismatch to happen, so it just barged ahead and did who knows what with that object of the wrong type, until it tried to look up a non-existent field, which *conveniently* returns null. This gets assigned to another field in another object, and *then* when that other object is finally used much later on, it gets a null dereference exception.

But this is JS we're talking about. What happens, boys and gals, when the JS interpreter encounters an uncaught error? That's right, it logs an error message to the error console (which is hidden by default in most browsers), and silently fails without any warning, and then the rest of the site's scripts (hooked to various event handlers) CONTINUE RUNNING AS IF NOTHING HAPPENED.  I'd really like to know which genius came up with this totally dainbramaged idea, because I'd *really* like to slap him upside the head.  Can you imagine the kind of field day the blackhats would have if, say, C code running on enterprise servers were to blindly continue running after dereferencing a null pointer?  And now they want to put JS on the *server*? Gives me the shudders...

Seriously, this is just like writing assembly code in 1975. Screw up a single opcode, and the computer just blindly barges onward interpreting random bytes as instructions, wreaking havoc to your entire system while you stare at the screen believing that it's still computing what you think you told it to. Who knew that JS was an underhanded way of getting people to write assembly code by hand again? :-P



> > > > But I've never used YAML, so I can't say whether or not I'd like it.
> > > 
> > > JSON is a subset of YAML 1.2, so they're very similar. Probably the most obvious differences are that you don't need as many quotes in YAML, and whitespace matters. I've had to deal with it some at work, and I hope to never have to deal with it elsewhere.
> > [...]
> > 
> > Wait, how can JSON be a subset of YAML if whitespace in YAML is significant, but it isn't in JSON?
> > 
> 
> Whitespace is only sometimes significant in YAML. On the JSON constructs, it's not significant. On certain (all?) of the non-JSON YAML-specific things, then it's significant.

Yikes. So whitespace is neither always significant nor always insignificant, but *sometimes* significant? Then I have to agree with Jonathan that YAML is truly evil!


T

-- 
All problems are easy in retrospect.

On Wed, Sep 11, 2013 at 10:40:30PM +0100, Russel Winder wrote:
> On Wed, 2013-09-11 at 15:17 -0400, Jonathan M Davis wrote: […]
> > that it's dynamic. It shouldn't be possible to do things like change the type of a variable based on whether an if condition was true or not (or change the type of a variable at all for that matter). I use python at work when I need to use a scripting language, because it's the best option that I have there, but otherwise, I'd just use D.
> […]
> 
> The type of variables in Python do not change. Python is a strongly typed language. The type of all variables is pointer to object.
[...]

That's an implementation detail. Does the Python *language* even have such a concept as a "pointer"?

In theory, any Turing-complete language can be implemented by any other Turing-complete language. Just because BF can be implemented in C, in no way implies that (the C implementation of) BF is a statically-typed language. Nor does the fact that Haskell can be implemented in C imply that Haskell has pointers.


T

-- 
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr

On Wed, 11 Sep 2013 15:50:52 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Wed, Sep 11, 2013 at 05:11:38PM -0400, Nick Sabalausky wrote:
> 
> Seriously, this is just like writing assembly code in 1975. Screw up a single opcode, and the computer just blindly barges onward interpreting random bytes as instructions, wreaking havoc to your entire system while you stare at the screen believing that it's still computing what you think you told it to. Who knew that JS was an underhanded way of getting people to write assembly code by hand again? :-P
> 

Exactly. I really do believe that's a very accurate way to put it.

I don't like the prevailing notion that such dynamic languages have strong typing. Yes, they *technically* have strong typing, but most benefits are thrown right out the window. So *in effect* it's mostly the same as not having strong typing at all - either way you're still getting tons of seemingly random, unpredictable, barely-tracable, and *potentially dangerous* behavior any time the slightest thing goes wrong.

Just because a language has addressed dangerous low-level behaviors doesn't mean it's addressed dangerous high-level behaviors. All they've really accomplished is make the same old problems and catastrophes operate on a higher level than before (but more slowly and with greater power drain). So like you said: Reliability-wise, they're just reinventing assembly.

> > Whitespace is only sometimes significant in YAML. On the JSON constructs, it's not significant. On certain (all?) of the non-JSON YAML-specific things, then it's significant.
> 
> Yikes. So whitespace is neither always significant nor always insignificant, but *sometimes* significant? Then I have to agree with Jonathan that YAML is truly evil!
> 

I don't know about evil. While I don't like indent syntax (it is one of the things I dislike about Python), YAML does at least make it *possible* to avoid both the syntax-fiesta of JSON and the anti-DRYness of XML, and YAML files *can* be constructed to be very easy to read. So I think that alone means YAML deserves at least *some* respect.

However, the problem I have with YAML is that it's complex, with various difficult-to-remember syntaxes. I'd feel that I'd have to be very, very careful when writing, editing or generating YAML. And yea, the "sometimes significant indenting" is certainly part of that complexity.

Fun fact:
Did you know Python's indenting is only "sometimes significant", too?

On 2013-09-12 00:50, H. S. Teoh wrote:

> But this is JS we're talking about. What happens, boys and gals, when
> the JS interpreter encounters an uncaught error? That's right, it logs
> an error message to the error console (which is hidden by default in
> most browsers), and silently fails without any warning, and then the
> rest of the site's scripts (hooked to various event handlers) CONTINUE
> RUNNING AS IF NOTHING HAPPENED.

My experience is that if a JavaScript fails, somehow, JavaScript fill stop working all together on the site. But that's perhaps not the case if an exception is thrown. But rather if you're trying to use a variable or similar that doesn't exist.

-- 
/Jacob Carlborg