Path: utzoo!attcan!uunet!mcsun!ukc!inmos!mph@lion.inmos.co.uk
From: mph@lion.inmos.co.uk (Mike Harrison)
Newsgroups: comp.lang.misc
Subject: Re: Cheap implementations of languages (Re: Pointers and poor implementations (was: Re: JLG's flogging ...))
Message-ID: <5507@ganymede.inmos.co.uk>
Date: 11 Apr 90 10:20:56 GMT
References: <5486@ganymede.inmos.co.uk> <14323@lambda.UUCP>
Sender: news@inmos.co.uk
Reply-To: mph@inmos.co.uk (Mike Harrison)
Organization: INMOS Limited, Bristol, UK.
Lines: 73

In article <14323@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>From article <5486@ganymede.inmos.co.uk>, by mph@lion.inmos.co.uk (Mike Harrison):
>> ...
>>   - DATA statements, with implied DO, which can be quite complex when you 
>>     have nested cases.
>
>Why should these be any harder to implement than nested run-time loops?
>Actually, I've implemented a parser for do-loop style data initialization
>for an I/O library.  It was not particularly difficult.
I should have given a bit more context here.
I recently did some work on this for the Transputer, which exposed two 
connected problems:

  - the way our loader works, we don't usually load initialised data areas
    direct, rather we load code to contruct the initialised area,

  - an implied DO type DATA statement such as:

      DATA ((X(J,I), I = 1, J), J = 1, 5) / 1 * 0, 2 * 1, 3 * 2, 4 * 3, 5 * 4  /
    
    initialises a triangular segment of the array thus:

      0
      1 1
      2 2 2
      3 3 3 3
      4 4 4 4 4

Now it clearly easy to write down good code to do this, but what if we change
the statement to:

      DATA ((X(J,I), I = 1, J), J = 1, 5) / 5 * 0, 4 * 1, 3 * 2, 2 * 3, 1 * 4 /
    
so that the initialisation is:

      0
      0 0
      0 0 1
      1 1 1 2
      2 2 3 3 4

then the generation of 'good' code is much harder. (And that example is not a
*particularly* bad one - it is easy to write difficult cases).

The real problem is analysing the statement to find the common (sensible) cases
for which you should generate good code.

> ...
>When comparing languages, one must have an eye for what features are
>really correspondent.  For the most part, procedural languages tend
>to all have pretty much the same features.  
It's often the way such features may be combined in the language (together with
interactions with the target architecture) which makes things more difficult in
some cases than others.

On the more general topic of 'pointers v arrays' (or even Fortran v C), I agree
with most of what you have said. 
The problem is not pointers 'per se', it is:
    - how pointer 'values' can be generated (ie. what you can 'point to'),
    - how pointer 'values' can be manipulated.

Thus, 'typed' pointer values (cf. Ada 'access type' or Algol68 'refs') with
restricted operations are not (usually) dangerous.
(and in languages which incorporated the 'recursive combinator' or 'letrec'
style declarations, explicit pointers are unnecessary).

Mike,


Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;