Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!ig!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <17036@megaron.cs.arizona.edu>
Date: 20 Jan 90 01:57:57 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 45

In article  <14199@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>For example, When I wish to pass an array to a procedure, Fortran (and
>Pascal, Modula2, ADA, ...) lets me do so.  In C, the procedure always
>sees a pointer instead of an array.

But in C there is no difference between an pointer and an array except
that the array is a constant.  And you can declare the argument to be
an array if you want to.  I really don't see what point you are trying
to make...

>  Another example: when writing
>numerical programs you often need to force the order of evaluation
>of an expression to avoid over/underflow or to eliminate cancellation
>in subtractions.  Fortran (pascal, Modula2, ADA, ...) lets me do so
>with parenthesis...

So here is an example where C can do more optimization and Fortran has
conveniences for numerical work.  It's a trade-off, just like those
cases where it is Fortran that can do more optimization and C that is
more convenient.

>>[about +=, *= etc. operators]
>...In fact, aside from C users, there seems to be no interest
>in these operators at all.

Icon has these sorts of operators.  Common Lisp has a special macro
(define-modify-macro) for constructing these sorts of operators.  So
there is at least _some_ interest in them.  I expect that of those
language designers who aren't interested in them, most have never
programmed much in a language that uses them.  They are very
convenient.

>One last reason that this is a bad example is that these operators work
>on the expression level and not on the statement level.  This is known
>(from several language design experiments) to be harmful to user's
>productivity.

Be more careful with your use of phrases such as "known to be".  There
are a _lot_ of of programmers and language designers who claim the
opposite.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman