Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!europa.chnt.gtegsc.com!howland.reston.ans.net!ix.netcom.com!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: Why is one OO language more productive than another?
Message-ID: <hbaker-1908950812290001@192.0.2.1>
Sender: hbaker@netcom18.netcom.com
Organization: nil organization
References: <40t027$7j9@hardcopy.ny.jpmorgan.com> <40tk13$qms@wcap.centerline.com> <4103gq$1pes@tigger.cc.uic.edu> <4133n5$mrf@wcap.centerline.com>
Date: Sat, 19 Aug 1995 16:12:29 GMT
Lines: 50
Xref: glinda.oz.cs.cmu.edu comp.object:37084 comp.lang.eiffel:10472 comp.lang.c++:144777 comp.lang.smalltalk:27396

In article <4133n5$mrf@wcap.centerline.com>, chase@centerline.com (David
Chase) wrote:

> dhanley@matisse.eecs.uic.edu (David Hanley) writes:
> 
> >       I agree with this 100%.  I would add more reasons that a very
> > short language definition is a good thing(tm):
> > 
> >       1) The compiler is simpler to write, and therefore more likely
> > bug free.  More time can therefore be spent making it produce more
> > optimal code.
> 
> I don't agree with this, especially the part about "more optimal code" (or at
> least the implication that the code produced for a language with a short
> definition will be faster than the code produced for a language with a long
> definition).  Language definitions are often made short by avoiding
> restrictions (e.g., no nested functions, nested functions may not be passed
> as parameters, nested functions may not be return values) which allow the
> implementor to "cut corners" -- e.g., allocate activation records on the
> stack instead of on the heap.  Fortran's definition includes a provision
> regarding the non-aliasing of parameters, which vastly simplifies the
> implementation of dependence analysis, which in turn enables some true
> strap-on-the-rockets optimizations (automatic parallelization and
> vectorization).
> 
> Modula-3 was an especially bad offender in this regard, I think.  It's
> easy enough to parse, but some of the features (opaque supertypes,
> multi-dimensional open arrays, structural type equivalence for non-branded
> types) require a decent amount of work under the covers to implement.
> It's not hard compared to actual code optimization, but it is difficult
> compared to lexical analysis and parsing of most languages.

The reason why non-aliased parameters are so difficult for the programmer
to deal with is the fact that they're not really in the source language.
A number of people, including myself, have made proposals to include
so-called 'linear types' into so-called 'high level languages' so that
issues like aliasing could be represented and dealt with at a level higher
than assembly language.

So, if you really want 'strap-on-the-rockets' optimizations, then your language
(and probably your hardware, as well) should start thinking about 'linear
types'.

Some references can be found in the following paper:

ftp://ftp.netcom.com/pub/hb/hbaker/Use1Var.html (also .ps.Z).

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
