Xref: utzoo comp.lang.c:8424 comp.lang.misc:1287
Path: utzoo!mnetor!uunet!husc6!ncar!gatech!mcnc!uvaarpa!umd5!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: The need for D-scussion (was Re: D Wishlist)
Message-ID: <719@l.cc.purdue.edu>
Date: 22 Mar 88 11:42:46 GMT
References: <12176@brl-adm.ARPA> <1988Mar11.215238.976@utzoo.uucp> <3073@haddock.ISC.COM>
Organization: Purdue University Statistics Department
Lines: 52
Summary: Do not put obstacles in the path of those who understand the computer!

In article <3073@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes:
> In article <27143@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes:
> >I am a computational number theorist who writes a LOT of code requiring that:
> >A*B/C [and] A*B%C be computed where A,B,C are all 30 bit quantities.  The
> >difficulty is that even though the algorithm guarantees that the results of
> >the computations fit in 30 bits, the product A*B may not. I therefore need to
> >make extensive use of any 'emul' and 'ediv' facilities that a computer may
> >have. ... Machines which have such instructions should, In my opinion,
> >generate emul/ediv code whenever it sees A*B/C and only return a run-time
> >arithmetic overflow if the quotient doesn't fit in the appropriate word-size.

I think Bob has oversimplified slightly and not asked for enough.  What I would
like to see is something like

	u,v = a*b///c

(or however he would like to write it; maybe eventually it would become
standardized, but it is not now).  What a reasonable language needs is the
ability of the user to define types and operations at will.  C++ allows the
introduction of types in some, but not all situations; it does not allow the
introduction of operators.

> Such a special case would be a wart in the language.  The "correct" way to do
> this is to provide an "lmuldiv" function which has the desired semantics (I'd
> have it return an ldiv_t structure, since it already exists in ANSI C), and
> encourage vendors to give their compilers the ability to inline it (along with
> other trivial functions, such as abs()).

This is precisely what has made it difficult for mathematicians, and all who
understand the computer, to make reasonable use of it.  To follow the desire
of the Mikado to "make the punishment fit the crime," I would sentence all 
those who would deny the right to use infix notation to others the right to
use it for themselves.  It is the use of prefix rather than infix notation
which makes assembler programming such a chore in 99% of the assemblers.

Furthermore, returning a list of values for a function is far different from
returning a structure.  In the case above, it is likely that everything
should be in registers.  And it takes no longer to produce the efficient
code with a reasonable language than it does to produce the less efficient
code with the "warts" removed.  In fact, it takes much less time to write
a reasonable notation.  It takes less time to read someone's reasonable infix
notation, even if that is not the way I would write it, than prefix notation,
if I have any idea of what is being done.

As long as programmers are taught to think in terms of a language, rather
than the machine, it will be difficult to get vendors to allow the forcing
of inline.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet