commentary

[Mark S. Miller <mark>]

Date: Sat, 18 Nov 89 22:50:19 PST
   From: heh (Hugh Hoover)

   ...  I have to say that
   the code is becoming very stilted, considerably larger, and very odd looking.
   Most of these are caused by the language simply not fulfilling the spec.  The
   "sorry, not implemented: ..." messages are causing a tripling in the size
   of many inner loops because && and || don't work with Vars (SPTR's), all
   (well almost) all returns become 2 or 3 lines of code, or require a completly
   unnecessary cast, etc, etc.  

I was afraid of this.  I consider this to be a serious problem for
which I know of no good solution.  I really really hate to even
suggest this, and please feel free to ignore this suggestion, but
maybe we should try g++?  They are trying to be C++ 2.0 compatible,
and we may expect that they are 1) taking the 2.0 documentation as
their spec, not the 2.0 compiler; and 2) there's no rational
explanation for the "sorry not implemented"s that we are running into
here, since they can each be removed by a semantics preserving
mechanical syntactic transform of the code--a transform which the
compiler could easily do instead of us.

The reason I hate to suggest this is two-fold: 1) Experimenting with a
probably-not-really-2.0-compatable-compiler will waste a lot of time,
and 2) What if it works?  We probably still have to make all our code
work with 2.0 cfront from AT&T, since that's what's out there and
wildly ported.  Since g++ doesn't compile to C, it'll never be as
widely available.  Also we'd have to deal with the obnoxious copy-left
issues (these can probably be gotten around though).

So please feel free to not try this experiment.

   Very little of this can be corrected by
   automatic translation fixes (unless Dean gets VERY clever and spends a
   considerable amount of time).

Well...  Some of these cases are easier than others.  I expect the
return case is easy.  Since "return expr;" is a statement, not an
expression, it should be straightforwards to expand it to:

result = expr;
return result;

We could declare "result" at the beginning of all translated functions
that are declared as returning a value.  Note that we only need the
function return type when declaring "result", not when expanding a
return.  This already fits with (at least my) coding conventions. (I
frequently employ just such a "result" variable anyway, inherited from
the DASL days.)

The translator probably doesn't generate either "for" loops or
initialized variables, so these won't be a problem for you guys.

&&, ||, and ?: are all probably really hard because they can occur
inside larger expressions, but they must be expanded using statements.
Having the translator handle this would make it into more of a
compiler than a translator, so let's do this one manually.  Oh well.

None of this helps the readability of the C++ code, or the task for us
poor slobs who are stuck in C++ as our source language.  Or our
developers, who generally will be similarly stuck.  Double oh well.

That's what we get from trying to develop in a language that's only
90% implemented!  Even in hindsight, I don't see that there was any
better alternative.

     Well, had to get that out of my system.  I not suggesting we stop the
   garbage collection work.

Agreed.  Despite these problems, it is indeed great work!

     Back to expanding loops!
   --Hugh

Back to expanding loops!
 Back to expanding loops!
  Back to expanding loops!
   Back to expanding loops!
    Back to expanding loops!
     ...
	     ...
	    --- MarkM
	   --- MarkM
	  --- MarkM
	 --- MarkM
	--- MarkM