Xref: utzoo comp.arch:21989 comp.lang.misc:7380
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Compilers and efficiency
Message-ID: <10205@mentor.cc.purdue.edu>
Date: 12 Apr 91 10:45:45 GMT
References: <27fa3350.6bc2@petunia.CalPoly.EDU> <11APR91.21114644@uc780.umd.edu>
Sender: news@mentor.cc.purdue.edu
Followup-To: comp.arch
Lines: 32

In article <11APR91.21114644@uc780.umd.edu>, cs450a03@uc780.umd.edu writes:
> Michael Turner writes:
> 
> >Guy Harris's example (if I remember correctly) was that no language he
> >knew of had semantics for retrieving both the integer quotient and the
> >remainder from a floating divide ...
 
> You mean like
>       0 3.141592654 #: 20
> 6 1.150444076

Translate, please.  Seeing the results, I still do not have any idea what
the instruction does or how to put the results in a useful place, probably
registers.

The problem with APL and other such wierdos (like 99+% of the assembler
languages) is their highly artificial syntax.  I can, even at my age,
learn the machine instructions quickly, but the stupid "mnemonics" of
assembler language are another matter.  This is what computer language
people do not realize; they seem to think that memorizing even highly
obscure notation is easy, and understanding slightly unusual operations
is difficult.

APL does have one feature lacking in at least most other languages; it
attempts to have a reasonably compact notation.  But there is no 
adequate macro processor available.  An adequate macro processor would
include the capability of easily translating APL into other languages,
for example, and even having the translation take into account types.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)