The Dink Network

I'm coming at this from the perspective of a dirty greasemonkey who works with the car every day, rather than the fancypants engineer that designed the engine. The engineer might say putting little rivets everywhere could be a good idea, but goddammit, fancypants, I ain't got no tolerance for that crap that don't even do nothing!

...or in other words, while semicolons and brackets might serve a function in theory, in practise such cases never seem to come up. There's a limit to how much you should bend over backwards just to be on the safe side; adding hundreds of redundant symbols to every script is well over that threshold, IMO. 'Course, should the car ever actually break down because I'm not adding the rivets everywhere, I'd immediately stop this negligent practise.

Also, in Seth's original notes he said, that including multiple assignments on one line would likely work fine, but there were occasions the parser didn't read them right, and suggested to put one per line just to be sure. There are examples in his own scripts that assign 2 on the same line, though only a few times this occurs.

This is extremely limited. If I remember right, it only works with if>then statements, like 'if (&result == 1) &strength = 1' or 'if (&result == 2) unfreeze(1)'. '&strength = 3; &defense = 1; ' doesn't work, even adding a comment after a command often doesn't. (Although Seth does that a lot in his scripts. Something like '&strength = 10; //STRENGTH' seems fine, while 'say("a cat goes to town",1); //a cat, dammit' doesn't work.)

Another point worth mentioning, when using compress to make .D files, it uses a pairing system to accomplish much of it's compression. White space within quotes will be packed as a literal string counting how many spaces there are, outside a string it is likely to choose the option that provides the most compression. That is, if you purposely leave extra white CRLF white space in a section, which should be parsed as a nop and allow the engine a few more slices to handle housekeeping chores, they may be ignored in the compression pairing, unless they have been marked with ; or { - } or //

That's an interesting point. I've never tried .D compression on my scripts (since no one usually does that anymore when releasing dmods), but having tested it just now with my test dmod, it seems to work fine.

Curly Braces:
If you are writing QBasic, in which line numbers not used by virtue of parsing CRLF to indicate a new line, then you could simply code without encapsulating your functions. However, in scripts that provide a function for multiple events: main(), talk(), hit(), for example, it can become important to identify where talk() ends, to prevent it from falling through and running hit(), as well.

But brackets for opening and closing procedures don't seem to fulfil that role in DinkC. The line about herrings gets said in this script:

void talk
{
say("a cat goes to town",1)
wait(1500)
}
say("the cat eats a herring-flavoured curry sandwich",1)
void hit
say("AAAAA",1) 
blargh

As it does in this:

void talk
{
say("a cat goes to town",1)
wait(1500)
}
}
}
}
}}}}}

say("the cat eats a herring-flavoured curry sandwich",1)
void hit
say("AAAAA",1)
blargh

If the brackets had any actual function in closing the procedure, I would think the procedure should at least close when you DO use them. Instead, DinkC just ignores the brackets.

Sometimes it may function well but there is no guarantee it will continue to do so. We should not presume the parser will remember to compensate for our omissions every time, just because it did a few times. Do not code scripts to take advantage of a bug in the engine, such scripts could fail if that bug is fixed in an updated engine.

I haven't wrapped procedures in brackets for years and years, and haven't encountered one problem yet. I think it's a pretty safe assumption that it won't suddenly stop working. Furthermore, as long as we don't use brackets to close procedures, it couldn't possibly be changed in a future engine, because that would break backwards compatibility. It's a feature, not a bug.