Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Cheap implementations of languages (Re: Pointers and poor implementations (was: Re: JLG's flogging ...))
Message-ID: <14334@lambda.UUCP>
Date: 11 Apr 90 06:34:59 GMT
References: <8960014@hpfcso.HP.COM>
Lines: 70

From article <8960014@hpfcso.HP.COM>, by mjs@hpfcso.HP.COM (Marc Sabatella):
> [...]
>>II) Feature differences.
> [...]
> What about
> c) math intrinsics and built-in I/O (including implied do-loops)

This is a discussion of implementation difficulty.  Math intrinsics CAN
be implemented as procedure calls -just as C does.  Built-in I/O _IS_
implemented with procedure calls on every system I've ever worked with
- just as C does.  Implied do-loops are a red herring in this discussion:
they are simply do loops that are completely simulated at compile time.
What's so hard about that?

> [...]
> d) equivalence

Already discussed in other postings.  In C, can you say 'union'?  I thought
so.

> [...]
> e) run-time dimensionable arrays

Again, in the context of simplicity of implementation, these are no harder
than statically declared arrays.  The dimension values are just variables
instead of constants.  Now, in an _optimizing_ compiler, these dynamic
array bounds limit constant folding to an extent (the bounds aren't constant).

> [...]
> f) entry statements

Again, not hard to implement in a _simple_ compiler.  It is the same
implementation as the normal procedure entry but with a jump around the
entry sequence code.

> [...]
> Then there are the curious two statements
> 
>>but there
>>are no new Fortran features which C doesn't already have a version
>>of.
> 
> and
> 
>>the Fortran 90 standard
>>makes use of these to provide generic functions which C doesn't have.
> 
> Well, the first statement is just plain wrong, and the second statement
> is a counterexample.  Fortran 90 a subset of C?

Am I the only one in this discussion who pays attention to the _context_
of the conversation.  In terms of implementation, the _new_ features
are similar to features already found in ANSI C.  Generic functions
require the same _implementation_ effort that function protocols do.
So, you have to add argument type tags to the symbol table entries
of generic functions, and the loader has to obey these type tags.
You have to do the same thing with function protocols.  The difference
is that the loader for Fortran 90 keeps looking if the type tags don't
match, the C loader issues a fatal error message.  The same difference
applies to matching function _references_ from within the code.

> [...]                   Or did we also forget about array slices and the
> bizarre control constructs which can be used to manipulate them?

No, I didn't forget.  The effort to turn all these into the equivalent
simple loops is trivial.  Such a dumb implementation would not be widely
approved (being slow).  But, we're talking about how difficult the feature
is to implement _simply_.

J. Giles