Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!snorkelwacker!ai-lab!ai.mit.edu!misha
From: misha@ai.mit.edu (Mike Bolotski)
Newsgroups: comp.lang.misc
Subject: Re: Multi-compilers
Message-ID: <1990Sep22.224055@ai.mit.edu>
Date: 23 Sep 90 02:40:55 GMT
References: <2581@l.cc.purdue.edu> <1990Sep22.061027.9223@d.cs.okstate.edu>
Sender: news@ai.mit.edu
Reply-To: misha@ai.mit.edu
Organization: MIT Artificial Intelligence Laboratory
Lines: 39

In article <1990Sep22.061027.9223@d.cs.okstate.edu>, norman@d.cs.okstate.edu
(Norman Graham) writes:
|> 
|> Second, it is simply naive to describe what a compiler does as
|> macro expansion. [ ... ] 

And then:

|> levels of reality. Personally, I chose to live in a reality where
|> lambda calculus is the underlying computational model. This implies 

Lambda calculus can be implemented little more than textual substitutions.
In that sense, macro expansion is almost sufficient as a computational 
model.  

|> in its instruction set. I disagree with this idea. In fact, the whole
|> RISC movement is founded on the idea that to build a faster computer 
|> you must _remove_ instructions from the instruction set. Likewise,

Not at all.  Refer to the endless "What is RISC" discussion on comp.arch.
 
|> adding an instruction to a modern computer will not increase its
|> computational power.

Sure it will.  Integer multiplication is sped up considerably by 
a hardware multiplier.  Again, see the interminable 16x16=32 etc etc
discussion on comp.arch. 
 
|> locations (ie. updatable variables, machine state). But by living in
|> this level of reality I gain the ability to write extremely clear and
|> straight-forward programs that are 10, 20, and sometimes even 30 times
|> _shorter_ than the equivalent programs written in a typical high-level
|> language. 

And consequently, 10, 20, or 30 times *slower* than typical high-level
languages.  Acceptable for some applications, not acceptable for others.

---
Mike