According to Albert van der Horst <albert@[EMAIL PROTECTED]
>:
> But with c comes the c compiler, the c libraries etc. If you have to
> call the c-compiler anyway, there is not much charm left in Forth.
Note that I am taking a boringly practical point of view. If we go
aesthetics, then "small is beautiful" and Forth ****nes, no doubt about
that.
Calling the C library does not necessarily mean that you invoke a C
compiler. It means that you call a function which is located in a shared
library and happens to use a C calling convention. Of course, using the
C language and a C compiler is the easy way for that, because if there
is one thing C does well, it is calling C functions. It also somewhat
helps a bit because source compatibility works better than binary
compatibility.
An interesting comparison can be made with JOGL. It is a Java API for
OpenGL; mostly, a quite direct translation of the OpenGL constants and
functions calls in the Java syntax. The good part of it is that they did
it with an automatic translation tool: they ran a kind of C syntax
analyzer which generated the glue code. This tool needs not be run by
every developer; it needs be run only when the OpenGL API changes, which
does not occur every day.
You could envision the same kind of system. Basically, you have a C
library call, say gethostbyname(). It takes as input a pointer to the
host name (a zero-terminated C string) and returns a pointer to a
"struct hostent". What may change between brands of Unix, or between
versions of the same Unix system, is the layout of that structure. A
tool could be made, which explores that layout and outputs the layout
information as a set of constants usable from Forth. It could even
produce Forth words which access the structure. In essence, you are
simply -- and automatically -- translating the C header file into some
data which conveys the same information but in a non-C syntax.
That translation process needs not be repeated often. If you perform it
on a single machine, then the result is usable on all machines which
ensure binary compatibility with that machine (i.e. all installations of
the same version of the system on similar architectures). On other
machines, you can use the translated information to call the
gethostbyname() function, and you need neither gcc, nor the
"development" library (i.e. the header files and static version of the
library).
The most complex part in the whole system is that in order to use a
shared library, you need to produce a dynamically linked binary, which
is somewhat more difficult than producing a static binary. Especially if
you do it without the help of the local linker.
> I tried to statically link a c-program
Static linking is not really sup****ted anymore on modern Unix systems.
The libc developpers got hold of the idea that dynamic linking is the
"normal" model, and thus began to disregard issues related to static
linking. Pretty soon, the libc became too heavy and interrelated to
allow reasonable static linking. This is a trait common to pretty much
all existing Unix-like systems. Some more advanced features are even
available only if you use dynamic linking (e.g. thread-local storage
with the '__thread' extension keyword of gcc).
Which means that if you need to access the functionalities offered by
the libc, then you must get them through the way that libc was meant to
be used, i.e. with dynamic linking. That does not change my point, which
is that the libc does offer interesting functionalities which are not
easily reproduced, namely that it is configured for interaction with the
rest of the system and the network.
> It may be frowned upon, but adapting lina to new versions of OS's is
> probably less effort than gforth keeping up with new version of gcc.
Gforth not only calls the C library, it is also itself written in C,
which is an altogether distinct situation than what we are talking here.
--Thomas ****in
|
