[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mathematical models
- To: blume@cs.princeton.edu (Matthias Blume)
- Subject: Re: mathematical models
- From: hbaker@netcom.com (Henry G. Baker)
- Date: Wed, 4 Jun 1997 17:30:41 -0700 (PDT)
- Cc: wand@ccs.neu.edu, Qobi@research.nj.nec.com, rrrs-authors@martigny.ai.mit.edu, hbaker@netcom.com, jgm@cs.cornell.edu, shriram@cs.rice.edu, ramsdell@linus.mitre.org, feeley@iro.umontreal.ca, kelsey@research.nj.nec.com, will@ccs.neu.edu
- In-Reply-To: <199706041410.KAA03719@mocha> from "Matthias Blume" at Jun 4, 97 10:10:54 am
> Now, having said all this it should also be noted that Scheme's
> mathematical definition (the denotational semantics section) is not
> only incomplete but also wrong. The mistake in it is later "fixed"
> using English, which is no good when you want to prove something. What
> I am talking about is the order of argument evaluation. In R4RS there
> is this funny "function" _permute_ together with _unpermute_ that is
> supposed to express the fact that the order is unspecified. As it
> stands using the semantics of R4RS one could prove properties that in
> reality do not exist. The missing specification only prevents us from
> proving things that are true, which is a mere incompleteness and not
> an outright mistake.
>
> Of course, getting this right is hairy, which presumably is why nobody
> has done it. (I would simply fix the order, which also has a couple of
> other advantages -- such as not having to explain the potential of
> unspecified behavior.)
> -Matthias
Once again, we will have to agree to disagree. If a language offers
side-effects, then it is either sheer silliness or sheer perversity
not to specify the order of evaluation of the arguments. As I have
said elsewhere, trying to write portable programs in such a language
_forces_ one to write essentially 'pessimal' programs, whose stilted
style cries out for comments in the margin apologizing to all future
readers for the cowardice of the standards committee.
The Ada language standard goes to extraordinary lengths to tell you
about the order of evaluation differences -- they allude to the fact
that the compiler has the freedom to not only choose a different order
for every call site, but they can even (nondeterministically) choose a
different order for every different invocation of the _same_ call
site! Since the cost of either a) proving mathematically that a
program cannot depend upon the argument evaluation order, or b)
providing test 'coverage' for all possible argument orders is
astronomical, I am fully prepared to read in the next issue of
comp.risks about how N people were killed by faulty software that
inadvertently depended on the order of argument evaluation in an Ada
program. This kind of nonsense is precisely why people in the
computer _using_ industries hate computer scientists -- somehow CS
people lost all their common sense in the process of getting their
degrees.
The efficiency gains possible by not specifying the order of
evaluation are so microscopic as to be unmeasurable in real programs,
whereas the efficiency _losses_ due to stilted programming styles and
maximal productivity are quite significant.
The Ada and C rules basically _force_ one to _never_ use nested
notation. That may not have been their goal, but that is their
effect. You have now forced the insertion of hundreds of thousands of
redundant temporary variable names, and the generation of millions of
lines of unreadable code. This is 'progress' ??
Let's stop the silliness right now!
--
Henry Baker
www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html