Re: language problem

[eric@burdvax.UUCP]

in article <6109@mimsy.UUCP>, dday@mimsy.UUCP (Dennis Doubleday) says:
> ....  But if it is impossible to efficiently handle
> type and constraint checking for every possible pathological
> boundary condition ...

At least in this example, the compiler can determine if the situation
could occur at execution time, and take appropriate actions by
emitting code for the efficient common situation, or less efficient
code for the pathological case.

First, the only operators which can partake in this silliness
are NOT and XOR, and only if their operand(s) is a subtype of
a boolean type constrained to a single value (Yuch). If such
a type may exist at execution time, the compiler could emit an
if statement like the following.

	if funny_boolean_type'first != funny_boolean_type'last then
		emit efficient code for AND and XOR
	else
		emit funny code for AND and XOR
	end if;

The funny code for AND is easy, just raise CONSTRAINT_ERROR (what
could be more efficient than that :-). For XOR, a component by
component test needs to be performed for the detection of
CONSTRAINT_ERROR.

So it turns out, for efficiency at least, that the XOR operation
is the worst case, AND is the best case, and for the common case
(a boolean type with both values), an additional if statement
is needed. Remember, all of this is only for a boolean type which
could turn out to be constrained to only a single value.


Eric Marshall
Unisys Corporation
P.O. Box 517
Paoli, PA. 19301
(215) 648-7223

USENET: sdcrdcf!burdvax!eric
        {sjuvax,ihnp4,akgua,cadre}psuvax1!burdvax!eric
ARPANET: eric@burdvax.prc.unisys.com