🚀 go-pugleaf

Matt Austern (austern@isolde.mti.sgi.com) wrote:
: In article <4l0si4$pqd@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel) writes:

: > : > >How would you have maintained C-style linkage and C++ typesafe
: > : > >linkage in the same object module without changing the linker?
: > 
: > : > By writing a linker pre-pass program which checks for and enforces
: > : > the type-safe linking rules.
: > 
: > : But such a program (a) would have to be rewritten for every machine
: > : to which C++ was ported, and (b) would not solve the problem of what
: > : name to give the linker for overloaded functions with the same name.
: > 
: > So?  
: > 
: > Eiffel and Ada and Sather compilers do it and their generics
: > work like a swiss watch.

: You mean you can link together object files produced by two different
: Eiffel compilers and it's guaranteed that the link will work?  If so,
: that guarantee is quite new: the last time I used an Eiffel compiler,
: it didn't even have such a notion as compiling a single source file
: into a single object file and then linking together the resulting
: object files.  The only user-visible files were the source (.e) files
: and the executable.  

Of course.  That's because there is not an agreement upon even the most
basic rudiments of a link representation for Eiffel, as there is for C. 

As long as operating systems will only come with linkers which are firmly
stuck in C mode this will persist. 

I don't think it even makes that much sense to compile a single Eiffel
source file into a single object file?  I don't even know exactly what it
would mean to have a single "object" file corresponding to a single
"source" file in Eiffel. 

: I certainly doubt if there's any portable way to compile part of an
: Eiffel program with one Eiffel compiler and part with a different one.
: The issue of source-level portability between Eiffel implementations
: is being resolved, but binary-level portability seems to be a very
: long way in the future.

It's not clear that 'binary portability' in a strict sense makes much
sense in Eiffel: a generic class which uses combinations of old library
code and new user-written code cannot just patch raw assembly together. 

The entire meaning of 'linking' depends profoundly on the language, and this 
is my point.  

So system 'linkers' ought to have been made which can deal with this
somehow, but they haven't.  Some might counter : "it's a 'people' issue, it 
is the responsibility of the language not the operating system".

I disagree---if there had been standard technology widely available which
could successfully link together things more sophisticated than C then the
various new language people would have been much more motivated to adopt a
real representation for doing so for every new language. 

I thus consider the design of the 'link model' for the Java VM 
very important.  What are the concepts that it can represent?  I think it
would be 

: Matt Austern
: SGI: MTI Compilers Group
: austern@isolde.mti.sgi.com