🚀 go-pugleaf

In article <1990Dec29.110202.3862@mathrt0.math.chalmers.se> augustss@cs.chalmers.se (Lennart Augustsson) writes:
> I apologize to those who find this trivial and think it's just
> a waste of time and space.

Ditto.

> Since Dan seems to hate computer science (or is it just computer
> scientists? Btw. what do you consider yourself to be Dan?) I will
> try to refrain from using computer science arguments.

I don't hate computer science or computer scientists, and I don't have
anything against ``computer science arguments'' (whatever those are).
I consider myself a mathematician, since you ask.

  [ analogy between functions and integers ]
  [ analogy between composable functions and arbitrary-precision integers ]

I agree that your analogy is reasonably close. For reasons outlined in a
previous article, I would say ``C supports arbitrary-precision
arithmetic'' just as strongly as ``C supports composable functions.''
(I am using ``supports'' to dodge the ambiguity of ``has.'')

However, there is one important failure of the analogy. Integers really
are an atomic type in C. Function pointers are not. C has first-class
arithmetic built in to the language. It does not have first-class
functions built in.

Of course, these statements about language power ignore issues of
efficiency and syntax.

> The problem with the counterclaim is that it talks about a completely
> different, newly defined type called func (integer), but the original
> claim was about another builtin type.

In this case, C does *not* have built-in first-class functions, unless
you abuse terminology and take ``has'' as something syntactic.

So what do you care about? If you care about what's built in, then you
can go nitpick with the ANSI word-mangling committee. If you care about
programming, you will solve the problem at hand and not worry about
what's built in and what takes a few lines of code to implement.

> Dan claims that there is no practical difference, but I think there
> is a very big one.  If I have tons of code that uses functions (ints)
> I would have to make massive changes to be able to use that code with
> these new type func (bignum).

The fact that function pointers are supported more strongly than struct
fun pointers is merely a matter of convention and history. Neither type
is built in to the language per se. (I am referring to K&R and common C.)

If I understand your argument correctly, you are saying that C ``has'' a
type if and only if you can find a big enough box of library functions
that depend on that type. This is insupportable.

Please don't misinterpret my statements here. I do agree that there is a
practical reason to use whatever code is available when it does the job.
But you started by saying that C doesn't have first-class (rather,
first-class composable) functions, and that's a theoretical statement
with a theoretical meaning.

> (You cannot write a total function that converts func to C functions any more
> than you write a total function that converts bignum to int.  The function
> has to fail (or give a "wrong" result) for some arguments.)

Actually, another poster illustrated a technique for doing exactly this,
with no failures. It's a rather nice solution, though it does require
ANSI C.

> To state my argument concisely:  If a predefined type X (function, int)
> does not have property P it does not matter if it possible to define
> another type that has property P, X still does not have it.

C does not predefine any type which is a first-class function! Why do
you keep saying it does?

Either you say that C has composable functions, or you say that C
doesn't have first-class functions (in the usual sense) at all. There's
no way out without an appeal to syntax.

I understand that you and Dave really are taking that way out, and I
think we are on common ground wrt what we mean. I just don't like mixing
syntax into a discussion of semantics. Next time I'll try to stay away
from phrases like ``C has X.''

> Since Dan's description of Q was rather short I cannot say anything
> about Q.  Is it the case that you can change anything without
> syntactical changes?  Without recompilation?

Without changes to the program text per se, always. Without
recompilation, of course not. For the purposes of this discussion, C++
works the same way.

> Anonymous voice says:
> FORTRAN is a subset of C.

This statement refers to much more than language power. In particular, C
cannot deal with certain features of Fortran syntax. Therefore Fortran
is not a subset of C. Why are you being facetious?

---Dan