[comp.lang.c] Expression syntax in programming languages.

jlg@beta.lanl.gov (Jim Giles) (07/01/88)

In article <5174@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes:
> Since when does 'x = x + 1' resemble anything besides an obviously false
> statement in mathematics??  Also, since many of us use C for tasks other
> than number crunching, does this mean that we should have NO desire for a
> programming language to resemble mathematics?  Your reasoning is a little
> faulty here.

But not as faulty as yours.  I maintain that the expression syntax
should be kept as close as possible to accepted mathematical conventions.
You seem to be maintaining that, because exact duplication is not possible,
the language designer shouldn't even try to be similar.  If you would
read my entire statement (in which I said that both C _and_ Fortran were
far from perfect), you wouldn't be accusing me of claiming that assignment
is a mathematical syntax.

> |The choice I'm talking about is whether to cause a function call (the
> |most expensive of all the 'simple' operations).  Doesn't matter what the
> |subroutine library does, you've already made the expensive call.
> 
> A function call may not necessarily be made (can you say 'inlining').

I can not only SAY it, I can also notice that C doesn't do it (as I've
pointed out before).  The C language definition (such as it is) doesn't
allow it.  The proposed ANSI C will, I am led to believe, address this
issue.
> 
> |Fine, C is fixing something that shouldn't have been broken to begin with.
> 
> It was never broken (a little inefficient, but not broken).

If the presence of an exponentiation operator can be considered as an
'error' in Fortran, then an inherently inefficient part of C can be
considered 'broken'.
> 
> |Finally!  Something we agree upon.  But what does this have to do with
> |the value of placing the operator into the syntax?  Just because it's
> |seldom used for large or non-constant arguments, doesn't mean it needs
> |to be arcane or cryptic when it IS used.
> 
> If all the arguments are constant, what do you need a run-time operator
> for?

The language used above was English.  I will attempt to translate it for
you.
Example:
I don't put cream in my coffee very often, but that doesn't mean that
cream shouldn't be available.
Example:
I don't use large, non-constant, or non-integer exponents very often, but
that doesn't mean it should be hard for me to do so if I wish.  Nor should
it be hard for me to use the small, constant, or integer exponents that I
use more frequently. (What's a 'run-time operator'?  All operators are
source code objects.)

Since I don't know what language you actually use, I can only hope that
several similar English examples will be sufficient.

J. Giles
Los Alamos

nevin1@ihlpf.ATT.COM (00704a-Liber) (07/08/88)

[followups to comp.misc]

In article <20520@beta.lanl.gov> jlg@beta.lanl.gov (Jim Giles) writes:
>In article <5174@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes:
>> Since when does 'x = x + 1' resemble anything besides an obviously false
>> statement in mathematics??  Also, since many of us use C for tasks other
>> than number crunching, does this mean that we should have NO desire for a
>> programming language to resemble mathematics?  Your reasoning is a little
>> faulty here.

>But not as faulty as yours.  I maintain that the expression syntax
>should be kept as close as possible to accepted mathematical conventions.
>You seem to be maintaining that, because exact duplication is not possible,
>the language designer shouldn't even try to be similar.

If you are designing a language specifically for mathematics, then using an
expression syntax consistent with mathematical conventions might be
desired.  However, most of what computers are used for is not for number
crunching.  What makes mathematical convention better than any other
convention??

Another thing:  people tend to think of the '+' operator (with respect to
some computer languages) as being the same as the one commonly found in
mathematics.  These operators do not exhibit the same properties, however
(in finite floating point arithmetic, addition is NOT associative.  I wish
I could remember who originally posted this fact).

>If you would
>read my entire statement (in which I said that both C _and_ Fortran were
>far from perfect), you wouldn't be accusing me of claiming that assignment
>is a mathematical syntax.

Very little of what computers do correlates directly to mathematics.
Mathematics is a declarative language, but computer languages are
algorithmic.

>> A function call may not necessarily be made (can you say 'inlining').

>I can not only SAY it, I can also notice that C doesn't do it (as I've
>pointed out before).  The C language definition (such as it is) doesn't
>allow it.

It has always been allowed (this is an implementation detail, not a language
detail).

>If the presence of an exponentiation operator can be considered as an
>'error' in Fortran, then an inherently inefficient part of C can be
>considered 'broken'.

Who said that the exponentiation operator is an error in FORTRAN?  But just
because FORTRAN has it, that is no reason to believe that every other computer
language should have it.  If it doesn't fit in well with the language
paradigm, then it shouldn't be kludged in.

The inefficiency is due to implementation details; it is not inherent in
the language.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				You are in a little twisting maze of
 /  / _ , __o  ____		 email paths, all different.
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah