HN Explorer

Ask HN: When data is code, what is the meaning of a config script?

7 points by phaedrus ↗ HN
As someone going from statically typed, compiled languages to a dynamic language, I'm in a philosophical quandary: when your language is sufficiently flexible to allow you to write your configuration settings files for the application in the same language as the application itself is written in, what does that mean? Is it even meaningful to consider your configuration data as distinct from your code?

I'm writing a game engine in a combination of C++ and the dynamic language Io. (http://iolanguage.com/) Some of the operational code of the engine will be written in Io scripts, while all of the configuration settings will be in Io scripts. (No need to invent a special text file format when Io's terse syntax makes it just as easy to specify settings data directly as Io code.)

It seems strangely arbitrary to make a distinction between the Io scripts that describe operational components of the engine, and the scripts that describe lists of settings. After all, they are both in the same, Turing-complete language. When I am writing my configuration settings, should I just pretend the language has less features than it does, restricting my Io code in the configuration scripts to just setting name-value pairs?

On the other hand you could go completely the opposite way and hardcode all the values in the scripts that comprise operational code. While this sounds like a recipe for a mess, it would satisfy our minimum goal for scripting the game engine, which is that we want to be able to change settings without recompiling the C++ code. It would certainly be simpler by some measure. Although you might be editing a settings value while it is surrounded by other very important code!

We don't have to go to either extreme, but when the data itself is also represented in code, there's no longer any imposed limits on the difference between configuration files and code files. Where would you place the distinction?

3 comments

[ 4.1 ms ] story [ 17.7 ms ] thread
Kliment
Well, as long as you are the only one editing them, it doesn't make a difference where you put the limit between code and data. This changes once you release though. Configuration files are meant to be user-edited as part of standard functionality, program code is not. Your users expect nothing major to break if there is a syntax error in the config file. Does that make your entire program crash with an undecipherable (to someone unfamiliar with the language or programming in general) error? You want to be as robust as possible when reading user-editable files, and directly executing them as code could cause problems. There is also the security and stability issue associated with encouraging users to enter code into a config file. Do think about it. This, to me, is the main reason for treating data as separate from code. You have to be robust about parsing data, your compiler has to be robust about parsing code.
CyberFonic
The most convenient way to have config files is to have a sensible default value for everything. So as much as possible the program should run in spite of config errors. If that is not possible, then the diagnostics need to be very explicit.

Any code, e.g. startup scripts should be ideally in a separate file. In the *NIX tradition these are usually of the form .foorc where 'foo' is the name of the app, and the '.' hides the file from normal directory listings. Ideally, it would be nice to pre-parse such startup code and only execute if it is syntactically correct.

cchooper
Several Lisp applications have config files that are just Lisp files run at start-up. Emacs is an example. You can (and people do) put absolutely any code in there. There's no need to restrict it to just setting variables.

So what's the difference between a config file and code? Config files aren't compiled (so no need to rebuild when you change them) and they are intended to be modified by the user, while other code isn't.