Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!husc6!mailrus!wasatch!utah-gr!uplherc!esunix!bpendlet
From: bpendlet@esunix.UUCP (Bob Pendleton)
Newsgroups: comp.arch
Subject: Re: Semantics (was Software Distribution)
Message-ID: <999@esunix.UUCP>
Date: 10 Oct 88 14:26:50 GMT
Article-I.D.: esunix.999
References: <13889@mimsy.UUCP>
Organization: Evans & Sutherland, Salt Lake City, Utah
Lines: 53

From article <13889@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek):
> In article <993@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
>>... I'm in favor of defining the
>>behavior of every operator in a language on all of its operand set.
> 
> Why?

So that I can know what the program is going to do without actually
having to run it. It is simply not possible to test a program on every
machine that it might some day be run on. How can I honestly sell a
program in MIIL or even in source code if I can't give some assurance
that the program will run correctly?

Defining the behavior of an operator on a specific subrange of
operands as a run time error is acceptable, and useful. In specific.
1/0, 0/0, *NULL, and sqrt(-1) should all, in my humble? opinion, cause
specific run time errors

> In particular, with regard to the more general statement, if we can
> improve the performance of a language on existing architectures by
> explicitly leaving certain semantics undefined, should we do so?  

NO!

> The
> argumentam [? ablative case anyway] pro is simple: programs run X%
> faster.  The argumentam con appears to be that programmers will use
> the construct anyway.  So what?  Those programs are then by definition not
> portable and may be considered just so many random bits: worthless.
> It is up to the programmer, and the buyer of programs, to make sure
> that programs in this language do not depend on undefined semantics.

Trying to avoid the religous argument lets look only at economics.

A year of software engineer time costs ~$100,000. Your mileage may
vary. I've heard numbers ranging from $70K to $150K. If I'm paying to
develop code, I can't take the chance that because of a poor language
definition my multimillion dollar program will turn out to be just
random worthless bits on the next generation of computers. Or, even
this generations computers from some other vendor.

For the cost of one year of porting effort I can afford to pay for an
awful lot of extra machine cycles. Not to mention that every year that
passes the cost of the cycles drops and the cost of engineering time
increases. So the argument gets stronger every day.

This argument fails when you start talking about programs that are
only barely possible on existing computers. But, that is the
exception, not the rule.-- 
              Bob Pendleton, speaking only for myself.
An average hammer is better for driving nails than a superior wrench.
When your only tool is a hammer, everything starts looking like a nail.
UUCP Address:  decwrl!esunix!bpendlet or utah-cs!esunix!bpendlet