OK, I've updated gpc and begun to probe for "clarification."
I'm glad an automated c-header translator is being discussed. The fpc people have such a tool and have translated libc. A terrific pascal development.
One issue to consider is naming conflicts. Since dot qualified names seem to be a problem, perhaps prepending the c library name to the pascal name will avoid name conflicts.
For example using the fpc unit "libc"; the libc function "close()" takes a file descriptor parameter, while the native pascal "close()" takes a file type parameter. Thus, the fpc libc "close()" is singled out and renamed in "unistdh.inc" to "__close()". (if memory serves me) Perhaps such a naming confusion can be avoided with all libc imports being named libc_name().
A libc unit for pascal is a big departure from the dos world. Other c-libs like OpenGL, etc. will follow.
I really don't care about ISO-this or ISO-that. Pascal is an elegant language that should allow casual programmers to tap into the c-library platform without too many paw prints.
Rick Engebretson wrote:
One issue to consider is naming conflicts. Since dot qualified names seem to be a problem, perhaps prepending the c library name to the pascal name will avoid name conflicts.
The last alpha release supports qualified identifiers.
What's more of a problem is that C allows the same identifier for different purposes (`int foo' can exist in the same scope as `struct foo', `union foo' or `enum foo'). Prefixing all structs/unions/enums with something unique might be a solution.
An even bigger problem is C's case-sensitivity. This will probable require some heavier name mangling.
A libc unit for pascal is a big departure from the dos world.
And I don't support the idea. Just as I think it was wrong for BP to promote Dos specific calls in the `Dos' unit (which we now have to painfully emulate for legacy code), and later Windows specific calls (so far as to suggest using C-strings (`PChar') in regular Pascal code), I don't think it's good style for any but perhaps some very special-purpose programs to use low-level system-specific calls.
Well, libc in general doesn't have to be system-specific, but unfortunately it often is, if you consider the number of autoconf checks (or equivalent) any nontrivial, portable C code (including our RTS) needs. Using libc in a Pascal program directly means the programmer would have to do all those autoconf checks himself -- translating the libc headers wouldn't help there (*) ...
To avoid this, we've already provided Pascal interfaces for much of libc's functionality (built-in and in the GPC module).
(*) Unless the translator would also do part of what autoconf does. In principle, that's possible, since it sees the declarations as it translates them. What it could not do (easily) is to check for functions that exist in the library, but not in the headers (that still occurs today -- *especially* in libc implementations --, that's why for many things there are separate autoconf checks for the existance and the declaration or a routine).
Other c-libs like OpenGL, etc. will follow.
I think most other libraries are easier to translate. With many libraries you have only one implementation, or a few (ncurses, PDCurses, ...), whereas many systems have their own libc. In addition, libc headers are often full of macros, and translating them automatically is very tricky.
(And, of course, a Pascal interface to OpenGL does not require a Pascal libc interface, even if OpenGL uses libc itself.)
I really don't care about ISO-this or ISO-that.
All of this is non-ISO-Pascal as it doesn't specify a way for external imports, anyway.
Pascal is an elegant language that should allow casual programmers to tap into the c-library platform without too many paw prints.
For commonly used things, I'd rather provide a proper interface (see above), so all the autoconf stuff (which often involves testing on different systems which a single programmer acnnot always easily do) must be done only once.
Frank
Frank Heckenbach wrote:
Rick Engebretson wrote:
One issue to consider is naming conflicts. Since dot qualified names seem to be a problem, perhaps prepending the c library name to the pascal name will avoid name conflicts.
The last alpha release supports qualified identifiers.
What's more of a problem is that C allows the same identifier for different purposes (`int foo' can exist in the same scope as `struct foo', `union foo' or `enum foo'). Prefixing all structs/unions/enums with something unique might be a solution.
An even bigger problem is C's case-sensitivity. This will probable require some heavier name mangling.
A libc unit for pascal is a big departure from the dos world.
And I don't support the idea. Just as I think it was wrong for BP to promote Dos specific calls in the `Dos' unit (which we now have to painfully emulate for legacy code), and later Windows specific calls (so far as to suggest using C-strings (`PChar') in regular Pascal code), I don't think it's good style for any but perhaps some very special-purpose programs to use low-level system-specific calls.
Well, libc in general doesn't have to be system-specific, but unfortunately it often is, if you consider the number of autoconf checks (or equivalent) any nontrivial, portable C code (including our RTS) needs. Using libc in a Pascal program directly means the programmer would have to do all those autoconf checks himself -- translating the libc headers wouldn't help there (*) ...
To avoid this, we've already provided Pascal interfaces for much of libc's functionality (built-in and in the GPC module).
(*) Unless the translator would also do part of what autoconf does. In principle, that's possible, since it sees the declarations as it translates them. What it could not do (easily) is to check for functions that exist in the library, but not in the headers (that still occurs today -- *especially* in libc implementations --, that's why for many things there are separate autoconf checks for the existance and the declaration or a routine).
Other c-libs like OpenGL, etc. will follow.
I think most other libraries are easier to translate. With many libraries you have only one implementation, or a few (ncurses, PDCurses, ...), whereas many systems have their own libc. In addition, libc headers are often full of macros, and translating them automatically is very tricky.
(And, of course, a Pascal interface to OpenGL does not require a Pascal libc interface, even if OpenGL uses libc itself.)
I really don't care about ISO-this or ISO-that.
All of this is non-ISO-Pascal as it doesn't specify a way for external imports, anyway.
Pascal is an elegant language that should allow casual programmers to tap into the c-library platform without too many paw prints.
For commonly used things, I'd rather provide a proper interface (see above), so all the autoconf stuff (which often involves testing on different systems which a single programmer acnnot always easily do) must be done only once.
Frank
I don't know how, in any detail, fpc accomplishes a monolithic libc unit. But I think gpc qualified identifiers will help build the bindings properly. I am not critical of anybody's work.
With my limited effort, the fpc libc functions are actually easier to use than fpc native functions. The man2html cgi program on staroffice5.2 (or tkman) gives quick reference to definitive man page documentation.
I just look at pascal as a far better superset of C than is C++. Ultimately, it all comes down to organizing bits.
Marco van de Voort wrote (by private mail, but I suppose it's ok to quote here):
: frank@pascal.gnu.de gave routing errors. Retrying with older address.
BTW, this mail domain moved to a new server recently. Sorry for any problems (also to others here who may have tried to reach me), I hope it's only temporary, and frank@g-n-u.de should work.
: I noted that Rick E. tried to make a point with the libc unit of fpc, : but his reasoning is flawed: ("c library revisited thread") : : FPC only supports the libc unit for kylix compability only and only on : linux/i386 distro's supported by kylix, and a best effort approach for the : others linux/i386 distro's. (this because linux glibc is a very instable : interface to follow with any release frequency that is larger than a few : months). : : His ease of use argument is also bogus, since everything is always easier if : you don't have limitations or portability concerns. : : We do offer a limited selection of Unix calls though, but these are targeted : for specific Unix use, and in no way a substitute for the general calls in : e.g. an unit sysutils. They are prototyped roughly as the C calls, but : with "fp" prefixed, so manual pages still apply.
This probably explains what Rick was wondering about. If even glibc interfaces changes frequently (I suppose so, I'm not following them closely myself), other system's libcs are vastly different ...
So the only way to get a portable libc access (without huge, and constant, rewriting) AFAICS would be either to have a 100% automatic translator that handles everything that occurs in some libc headers (which is likely to be all of standard C + extensions, via macros and inline functions), or to write wrappers in C that use the libc routines in the C way (thus being able to include headers as designed) and provide a well-defined C/Pascal interface. That's basically what we do in the RTS for a subset of libc (sometimes providing a bare-bones interfaces, sometimes higher-level).
As I wrote the other day, automatic translation for most other C libraries is probably a whole lot easier (as glibc headers contain some of the most complicated macros I've seen so far in external headers, apart from the Linux kernel headers) ...
Frank