Re: config(5) break down

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B