Mirsad Todorovac wrote:
I couldn't agree with you more. GPC is a great step forward in a fight for diversity, if it isn't anything else. It would be very nice to have all kernel calls available in GPC via a library, so one could also write system programs in GPC.
I partly agree. There are system calls for very specific purposes (say, mounting, loading modules, or even single-purpose calls such as sync() and reboot()). They are used by the corresponding utilities, and those utilities exist (though written in C), and are well tested over the years. I see no real point rewriting those utilities, just for the sake of it. If a higher level program really wants to performs those tasks (such as mounting, module loading, syncing, rebooting), which would be a rare situation anyway, I'd prefer to call the external utility actually. Basically, as Rick wrote about shell programs -- this is, of course, possible from Pascal programs as well, and it'll probably be more portable.
So, such kinds of system calls aside, there are still a number that should be made available to GPC programs IMHO. I've done some of them in the RTS, but mostly on an as-needed basis so far. I'll probably add more when I get to it and/or need it, and if you like to, you're welcome to help.
But please keep in mind portability. Unix tools, and especially GNU tools, gained popularity also because of their portability (across Unix systems, and mostly also to Dos, Windows and Mac now). Using autoconf, e.g. in the RTS, will help here quite a bit. BTW, I think in this regard, we're also in a better situation than C programmers. They have to auto-check the features in each single program (or use a portable library layers -- I've seen some attempts, but none seems to have widely spread yet). In GPC, if we do it in the RTS, it will be available for all GPC programs, without the need to find and install an external library, and tested with the installation of GPC (provided, of course, you write test programs for the new routines, which I stronly encourage).
I agree with you that stability is much more important than "new" things when writting system-level software.
I certainly don't object to the importance fo stability. Just please keep in mind that stability it still something we strive to attain in GPC in the first place, considering its history starting as a hacked C compiler frontend, and seeing that until a few years ago, compiling with optimization and/or debugging info (leave alone both), or using a number of problematic features (including schemata) was more or less suicidal. ;-) I think we've made significant progress up to now -- the number of known bugs on the to-do list and in the test/todo directory is at an all-time low now (22 programs in the latter, most of which are actually new feature requests, and of the remaining few bugs, most are rather exotic situations). There are still some problems on 64 bits targets and some less common systems, and Waldek is working to fix them. Once most of them are fixed (and no new short-term bugs are present), I think we can really call GPC a stable compiler for the first time.
From then on, of course, I'll try to preserve this level of
stability in future releases (except possibly alpha releases, as recently discussed).
Frank