Path: utzoo!attcan!uunet!husc6!think!ames!pasteur!helios.ee.lbl.gov!nosc!humu!uhccux!lee
From: lee@uhccux.uhcc.hawaii.edu (Greg Lee)
Newsgroups: comp.arch
Subject: Re: Semantics (was Software Distribution)
Message-ID: <2472@uhccux.uhcc.hawaii.edu>
Date: 7 Oct 88 02:59:34 GMT
References: <13889@mimsy.UUCP>
Organization: University of Hawaii
Lines: 31

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.
" ...
" I disagree.
" 
" 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?  The
" argumentam [? ablative case anyway] pro is simple: programs run X%
" faster. ...

Why would programs run any faster in a language with some undefined
semantics?  To make a comparison, the same programs would have to
run in both versions of the language, and so could not make any
use of the semantics undefined in one of the versions.  So why
then would the definition of semantics cause a program which does
not use it to run slower?  I suppose you could arrange things that
way, but why would you need to, or want to?

"  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.

This appears to assume your conclusion -- that a proper version
of the language may leave syntactically correct constructions undefined.

		Greg, lee@uhccux.uhcc.hawaii.edu