Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!usc!apple!uokmax!d.cs.okstate.edu!norman
From: norman@d.cs.okstate.edu (Norman Graham)
Newsgroups: comp.lang.misc
Subject: Re: Multi-compilers
Message-ID: <1990Sep23.070558.17433@d.cs.okstate.edu>
Date: 23 Sep 90 07:05:58 GMT
References: <1990Sep22.224055@ai.mit.edu>
Organization: Oklahoma State University
Lines: 60

From article <1990Sep22.224055@ai.mit.edu>, by misha@ai.mit.edu (Mike Bolotski):
> 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.

Yes. But no reasonable lambda calculus compiler would choose macro
expansion as its compilation technique. Thus my point stands.

> |> 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. 

Tisk, tisk. I didn't say adding instructions/hardware wouldn't increase
the speed of a computer. I was talking about the class of problems the
computer can solve. I mean, once you have Turing completeness... [OK, so
we don't really have that; but we can pretend right?] I thought my
discussion of the computer as an abstraction machine made that clear.

> |> 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.

You've not looked at the recent compilation technology for functional
languages--we're closing the gap. Within the year, I expect to see 
functional systems produce code that is only 2 or 3 times slower
than the code produced by the typical high-level language compiler.
[Much of that overhead will be eaten up by the garbage collector, etc.]

There are many programs that can live with that kind of performance
hit, especially given the wins on the points of readability, 
writability, and maintainability that functional languages offer.

But I agree with you: Functional languages are not the appropriate
choice for every problem--I never implied that they were.

--Norm
-- 
Norman Graham   <norman@a.cs.okstate.edu>   {cbosgd,rutgers}!okstate!norman
The opinions expressed herein do not necessarily reflect the views of
the state of Oklahoma, Oklahoma State University, OSU's Department of
Computer Science, or of the writer himself.