Path: utzoo!attcan!uunet!bu.edu!snorkelwacker!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!udel!carroll
From: carroll@udel.edu (Mark Carroll <MC>)
Newsgroups: comp.lang.misc
Subject: Re: Algol, and language design
Message-ID: <25767@nigel.udel.EDU>
Date: 27 Jul 90 01:16:25 GMT
References: <25630@cs.yale.edu> <58091@lanl.gov> <1990Jul26.024449.1777@esegue.segue.boston.ma.us> <2406@l.cc.purdue.edu>
Sender: usenet@ee.udel.EDU
Reply-To: carroll@udel.edu (Mark Carroll <MC>)
Organization: University of Delaware
Lines: 84

In article <2406@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
]> 
]> How about nested scopes and recursion?  I find them handy from time to time.
]
]Nested scopes of DO loops are present in Fortran.  Mathematicians have used
]recursion for ages, and the problems with implementing recursion in the
]architecture of the time were horrendous.  Frankly, some of them still are.
]What language allows carrying globals in registers across recursion?
]

I'm sure that everyone and his brother is going to jump on you for this,
but I'll join the bandwagon. This post is SO full of blatant proofs that
you know very little about language design. I don't mean to turn this into
a personal attack - but I really think that perhaps, as a statistician, you
should realize that you aren't an expert on computer language design.

Anyway, the really big error in the above quoted paragraph is the
statement "Nested scopes of DO loops are present in Fortran." I don't
think you understand what we mean by nested scopes. A scope is the region
across which a variable declaration or binding is valid. In Fortran code,
within the main program, a variable is either declared or not, for the
entire body of the main program, that is, the scope of any variable in
the main program is the entire main program. Now, to show you a nested
scope, I'll jump into C:

{ int i=<expr>;
  int j=<expr>;
 
  ..code section 1.. 
  while (i<j) {
    int k;
    ..code section 2..
  }
  ..code section 3..
}

This code fragment contains two scopes: the outer scope where i and j are
declared, and an inner scope, where k is declared. The scope of variables
i and j are code sections 1,2, and 3. The scope of k is only section 2.
The scope of section 2 is a nested scope. Why do we consider this useful?
Since k is only used inside of the body of the while loop, we'd like to 
have it only defined there, so that it can't be accessed outside of the loop. 
(Things can get better in C++ and Ada, where loop indexes can be scoped only
for the body of the loop, so that the programmer can't use the (unpredictable)
post-exit value of the loop index.)

The other major problem in the quoted section in your remark about the fact
that recursion was hard to implement. The purpose of programming languages
is to allow you to simply express operations that would be extremely difficult
to express on the real architecture. A technique like recursion is incredibly
useful - to disallow using it in a supposedly general programming language 
would be foolish. 

My personal problem with this whole discussion is that I think we want different
things from a programming language. What you're looking for in a language
is a fancy macro assembler. Personally, I have no interest in that. What I
look for in languages is a way to express my algorithm in a model of
computation that is different from the underlying architecture of my machine. 
If it less efficient than it would be in assembler, I don't particularly care.
I'm not looking for speed - I'm looking for the best way to express my
algorithm in a natural way. I like object-oriented programming languages
for certain jobs, because they let me express the relationships between the
objects that I am manipulating in a natural way. For other jobs, I like a
language like C, which is almost a portable assembly language. For yet
other jobs, I like a functional language, because they provide me with
a clean way of expressing certain kinds of mathematical relationships. 
A language provides with a clean expressive mechanism that is independant
of my underlying architecture. That's not always what I want - sometimes
I need to be close to the architecture. But the fact that I'm not close
to the architecture is NOT a flaw in the language I'm using - it's a 
feature of the language!

Finally, on the comment about compilers including global variables
in registers accross recursions - I could recommend some good papers
about interprocedural register allocation that talk about compilers that
can do exactly that - and more.

	<MC>

--
|Mark Craig Carroll: <MC>  |"We the people want it straight for a change;
|Soon-to-be Grad Student at| cos we the people are getting tired of your games;
|University of Delaware    | If you insult us with cheap propaganda; 
|carroll@dewey.udel.edu    | We'll elect a precedent to a state of mind" -Fish