Proliferation of operators (was: C Builtin Functions)

[KW Heuer]

In article <1418 at mmintl.UUCP> franka at mmintl.UUCP (Frank Adams) writes:
>In article <788 at bentley.UUCP> kwh at bentley.UUCP writes:
>>I can feel the flames ("More operators?  It's getting as bad as APL!").
>
>"More operators?  It's getting as good as APL!" -- except that it still
>falls way short in this respect.  I'm serious; APL does *not* have too many
>operators.  It does have too little structure.

The primitive functions in APL correspond roughly to C operators *and* the
entire runtime library.  I agree that APL does not have a problem there.

APL has its own character set; C is restricted to a subset of ASCII.  The
size of the alphabet is not a serious problem since new operators in C may
be multi-character; however, this may make them less mnemonic.  (Of course,
some of the APL characters are not all that mnemonic either: "x" for signum
is a good example.)

The reason APL can deal with having so many primitives is that they all have
the same precedence.  Adding that many operators to C would be a disaster.

You say APL has "too little structure".  If you mean things like "while" and
"if", I think they may be unwelcome.  Put in a "while" loop, and people will
start using it to implement a matrix multiply.  (For those who don't get it,
APL has a builtin matrix multiply, "+.x".)  The language doesn't need much
program structure, because it has data structure in its place.

Now, I *would* like to see some improvement in the data structure.  It's now
practically impossible to write a function which expects, say, three string
(character vector) arguments.  I like the grounded tree model, myself, as a
fix for this.  Also, APL is *severely* in need of *variable declarations*!

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
*** Please restrict followups appropriately! {net.lang.c|net.lang.apl} ***