> But C include files are a disaster - [...]. > As a user of the things I'd much rather all that just happened > automatically, when I use fopen() if the compiler needs stdio.h, it > should just go and get stdio.h - it's absurd to make me explicitly > say I need it.
That means that either: (1) Certain "blessed" libraries (stdio, in your example) more or less have everything they export turned into reserved words, not usable for other purposes. Non-blessed routines work the way they currently do. (2) The compiler knows about all include files everywhere - effectively, (1) with everything being blessed. (3) There's something else you do to make the link between the fopen name and stdio.h (or wherever stdio's declarations are kept). Of these, (1) is perhaps easiest, especially if "blessed" is defined as "in the C standard" or "in POSIX" or some such, thus avoiding bikeshedding about what gets to be blessed. However, it has two problems: it makes it impossible to write routines of your own with the same name as a "blessed" routine, even if you're not using the library in question (for exmaple clear(), erase(), and addstr() are all routine names I very plausibly might use in a non-curses-using program.) We have enough expropriating of perfectly good routine names going on already; at least twice I've tried to port a program forward only to find that the new OS version has taken over a used-to-be-user-namespace name the program used. It also doesn't fix the whole problem, leaving the current situation in place for everything but the magically blessed files. As for (2), that's basically impossible to implement unless you forbid programmer-provided include files. This leaves you with no way to implement the functionality such include files provide today. And as for (3), that's basically just a new spelling for #include; it doesn't really fix anything. > For C, because of the nature of the world 30+ years ago, and > development since, there's nothing we can do about it. But copying > that as if it was a great system would be absurd. I think it's less a matter of being stuck with history and more a matter of the goals being very different. The constraints affecting C includes and driving the design of the paradigm are substantially different from those behind config's files.* files. (This is not to say that C-style includes are wrong for config, just that they're not automatically right either.) I don't really have a comment on the question of config's input syntax. I think it's already split up too far; on multiple occasions I've had to "find /sys -name files.\* -print | xargs mcgrep -H SOMETHING" to find the config lines for something. However, changes to config are unlikely to affect me, so it doesn't matter in a practical sense. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B