Peter Gerwinski wrote:
Be welcome! :-) But first have a look on what is already there (ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/) and what is needed (see below for one suggestion).
- A standard (borland or watcom or something) Pascal library
reference (or one of each type to write multiple libraries :), with descriptions of what each does etc.
I have never seen a Watcom Pascal compiler. The only de-facto standard I have seen in Pascal libraries are Borland's ones.
As far as these are concerned, we now have everything of the non-object oriented units (i.e., except Turbo Vision and OWL), apart from the "Graph3" unit (primitive turtle graphics, probably not exactly in wide use ;-) and a few details.
Other more or less "standard" libraries I heard of are some units by Turbo Power which seem to be some extentsions to the Borland units, and the units of Delphi. I saw the interface of Delphi's SysUtils units, and it's quite large and would require a lot of work to implement.
Yes, I realize that this may be a huge task (how long did it take them to write the DJGPP2 libc? :), and that it would take a little while, but hey, it sounds interesting :) and you could take that little 'con' out of the cons section. In addition, non-C (but Pascal) programmers could use your compiler because you'd have a similar-to-Pascal-lib, and they wouldn't have to 'decipher' the c reference :).
NOTE: Just in case I wasn't clear, what I meant by writing a "standard Pascal lib" is writing the lib that is to Pascal as libc is to DJGPP :)
There is no library in Pascal that corresponds to `libc'. The closest thing is GPC's run-time library which implements Pascal's `writeln' and such. But that one is ready and working well. ;-)
Yes, exactly. If you meant to re-implement the libc functionality in Pascal, I doubt whether that would be such a good idea. The implementation of libc, AFAIK, is quite system-specific, but its interface on the C level is rather portable, so it seems more sensible to use this interface, like the RTS does now, than to reimplement it.
I recently added some functionality from the libc to GPC (e.g. some routines about file name, file name matching and globbing and getopt parameter parsing). The way I did it was to write a (thin) C layer over the libc interface if necessary to use C macros or such things, then a small Pascal layer if necessary to convert from or to Pascal strings (which are not easy to access from C code) or such stuff, and finally provide a Pascal declaration. This seems to be the best way for now. You can get the most recent GPC source distribution and see some examples of this in the rts/ directory (e.g., the unit filename.pas). However, not all the things I mentioned above are in that distribution yet, so if you want, we can provide you with the more current developer sources that contain them all.
There are certainly a lot of things left in the libc and other libraries (portable ones as well as system dependent ones) that could be made available to Pascal in this way, and if that's what you like to do, you won't get out of work soon... ;-)
Another (better, IMHO, but more difficult) approach would be writing a C-header-to-Pascal translator that translates a C header with all the details to Pascal in order to be used with GPC. If we had this, we could use libc and other libraries written in C directly from Pascal. This would take away not only the work of translating them and writing wrappers, but also the maintenance work and probably a lot of portability problems.
However, writing such a translator is not easy. Yes, there are a number of "C to Pascal translators" available, but none of those I saw came even close to being useful for this purpose because they only provide a more or less close approximation of the C code and declarations in Pascal. But what we need here is really a 1:1 translation -- which *is* possible in GPC for almost all features of C. Peter and I have discussed this problem and came to some conclusions about how to approach it.
So, if you like to try this (which wouldn't exactly be writing a library, but making available a lot of existing libraries), we can discuss with you our ideas so far.
Frank
-- Frank Heckenbach, frank@fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan