🚀 go-pugleaf

In article <4ktqv7$1ueu@piglet.cc.uic.edu> dhanle2@icarus.cc.uic.edu (David James Hanley) writes:

> : In order for a standard to have any meaning at all, that standard has
> : to specify the behavior of something.  Moreover, any standard has to
> : do so in a way that makes it possible to determine whether that 
> : something meets the requirements of the standard or not.

> 	Sure.  I gues this is so hard that standards are never 
> made, eh?

There are many things for which standards are not made, precisely
because it is impossible to detect conformance or nonconformance
to specifications for such things.

As a simple example, the C standard says that implementations are
required to produce diagnostic messages when presented with programs
that contain certain kinds of errors.  The standard does not say,
however, that the messages must correctly describe the errors.  The
reason for that is that there is no objective way to determine whether
a particular diagnostic message is correct.  It might be possible to
determine correctness for some messages, but no general decision
procedure is known.

> : Now, suppose a name-mangling standard existed.  What would it
> : specify the behavior of?  Linkers?  What is a linker?  What if I
> : give you a C++ implementation that has no linker at all?  Would you
> : claim that such an implementation cannot be standard conforming
> : because it does not have mangled names for you to inspect?  There
> : is no such requirement on C implementations; why should there be
> : such a requirement on C++ implementations?

> 	Again, so all those libraries I link with my C code must
> be figments of my imagination.  It would be just too hard to 
> agree on a standard implementation.

It is easy for vendors to agree with each other on an implementation
strategy, if that is what they want to do.  It is much more difficult
to write down rules for testing implementations (which is what standards
are) with the property that conforming to the rules will guarantee
compatibility.

If vendors want to be compatible with each other, no standard is
necessary.  If they want to be incompatible in areas ouside the
language proper, it is hard to understand how any standard can
prevent them from doing so.

> : Or what if I write a linker that does not use name mangling at
> : all, but instead stores types in its symbol table?  Would you
> : reject such a linker because it does not mangle names properly?

> 	Agast!  That couldn't possibly be part of the standard!

Please answer the question.

> : Of, for a third example, consider a compiler and linker that does
> : follow the hypothetical name-mangling standard, but gives its users
> : no way of determining what names it actually uses?  Does such a
> : compiler/linker pair conform?  How can you tell?  How can you test
> : conformance?

> 	I may be really stupid, but I don't understand at all what you
> mean here.  Wouldn't the names it uses be determined by the name mangling
> standard?

If you can't convince it to tell you what names it uses, how can
you determine whether it conforms to the standard or not?

> : Indeed.  But having a name-mangling standard would not affect this.

> 	Yes it would.  it wou;dn't clear up every concievable possible
> theoretical problem, but it would be another big problem out of the
> way of simpl distribution of libraries, object files, etc.

So you claim -- but I have yet to see any evidence to support that claim.
-- 
				--Andrew Koenig
				  ark@research.att.com