|Multi language programming guerin@IRO.UMontreal.CA (1995-11-03)|
|Re: Multi language programming firstname.lastname@example.org (1995-11-12)|
|Multi language programming email@example.com (Dave Lloyd) (1995-11-13)|
|Re: Multi language programming guerin@IRO.UMontreal.CA (1995-11-17)|
|Re: Multi language programming firstname.lastname@example.org (1995-11-20)|
|Re: Multi language programming Robert.Corbett@Eng.Sun.COM (1995-11-21)|
|Re: Multi language programming email@example.com (Dave Lloyd) (1995-11-27)|
|From:||firstname.lastname@example.org (Shankar Unni)|
|Organization:||Silicon Graphics, Inc., Mountain View, CA|
|Date:||Mon, 20 Nov 1995 16:25:44 GMT|
Dave Lloyd (email@example.com) wrote:
> This isn't sad. This really is expected. And desirable. Most
> languages (even C, but particularly Ada, Algol68, Fortran90) leave a
> great deal of flexibility in representation to the implementor.
Au contraire, this is sad, and undesirable. It only makes sense for those
people who do not use a single line of code that they do not recompile
themselves (i.e. totally self-contained software packages that do not
depend on *any* system library - not even libc).
There is a very great need for some sort of an "ABI" for each language on
each machine. Otherwise, people who want to buy "canned" libraries
(pre-compiled at the factory, or at some download site) are out of luck if
their compiler does not match the compiler used to build the library.
For languages like C, there generally isn't much of a problem, because
calling conventions are generally very simple, and there is little you can
do to violate it. For languages like C++ and Ada, there is a great deal of
variation in implementation techniques, which means, for instance, that you
can't mix gcc- and cfront-compiled C++ libraries.
Shankar Unni E-Mail: firstname.lastname@example.org
Silicon Graphics Inc. Phone: +1-415-933-2072
Return to the
Search the comp.compilers archives again.