From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: alt.folklore.computers,comp.lang.misc
Subject: Re: BCPL
Date: 28 Jan 1993 09:42:13 GMT
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
	<1993Jan25.182113.6275@osf.org>
	<SPACKMAN.93Jan26143219@disco-sol.dfki.uni-sb.de>
	<1993Jan27.184603.4204@osf.org>
Reply-To: stephen@acm.org
NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
In-reply-to: dbrooks@osf.org's message of Wed, 27 Jan 1993 18:46:03 GMT

In article <1993Jan27.184603.4204@osf.org> dbrooks@osf.org (David Brooks) writes:
|Well, I don't want to get into a pointless argument about a virtually
|obsolete :-( language.  I'll just point out that BCPL features (a) separate
|compilation and (b) no type declarations.  So a procedure parameter's
|actual type is not necessarily known at thetime of compilation.

I don't think the argument is at all pointless, or at all
language-specific. Lisp, for instance, has separate compilation and no
type declarations, and is far from dead.

|Absent a very smart object format and linker, there is no way to recover
|the type information in the way you suggest.

Well, first of all there's nothing wrong with smart linkers. Secondly,
there's nothing wrong with delaying code generation until runtime (see
the Self material, e.g.). Third, unless the language has a REQUIREMENT
of separate compilation - no more than one function per compile - this
argument is completely irrelevant, because only EXTERNAL interfaces need
be preserved (and it is often well worth compiling two versions of a
function, one for local use and one for external use, in today's
memory-cheap world). And it still applies to locals, which are frequent
and often the most important in pointer-heavy code (at least if BCPL
works out looking anything like C, which I strongly suspect it does).

Recovering type information is not as hard as you imagine, most
especially in cases like this where the conversion is relatively cheap,
because the job doesn't have to be perfect, it only has to be safe.

So I still think that BCPL and C quite clearly exhibit more or less the
same formal semantics on this point, the differences being that C is
source-typed so that the programmer *thinks* about it, and that the
descriptions given in textbooks are divergent - which descriptions are
NOT binding on the implementation.

Look, if this helps, a lisp compiler will keep arithmetic operands in
registers and represent many "boolean" values (in lisp this means that
they are either nil or *anything* else) as condition codes or branch
targets. This is *despite* the fact that the textbook describes them as
being pointers to values in memory. If you can't tell, it doesn't
matter, and the fact that a compiled function might call or be called by
an interpreted one is simply irrelevant, so long as the compiler is
informed that the possibility exists (and it is).
----------------------------------------------------------------------
stephen p spackman    +49 681 302 5288(o) 5282(sec)    stephen@acm.org
      dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany
----------------------------------------------------------------------
Newsgroups: alt.folklore.computers