Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!mirror!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.misc
Subject: Re: Expression Based Language
Message-ID: <11442@haddock.ima.isc.com>
Date: 17 Jan 89 02:24:46 GMT
References: <3300001@uxg.cso.uiuc.edu> <3290002@hpctdls.HP.COM> <11398@haddock.ima.isc.com> <2734@ficc.uu.net>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 32

>>>	a = for(s1;e;s2)
>>>	Is this legal? If e fails, is the value s1?
>
>>[reasonable, but s1 and the for-body would have to have matching types.]
>
>I don't see why.

I meant that they have to be compatible in the same sense as the ?: operands,
i.e. it must be possible to bring them to a common type.  It would not be
legal to write
	a = for(int_expr; e; s2) string_expr;

>>>I think the value of a statement with varying types is soluble by looking
>>>at the coercion needed to use it in context.
>
>>Context outside of the expression itself?  I think that's dangerous ground.
>
>That's the way it currently works for ?:.

We must be talking about different things.  I agree that it is possible to
assign a type to any statement whose component types are sufficiently
compatible, in the same way that ?: does%.  I believe this is what I said in
my first posting on the subject, in fact.  In the case of incompatible types,
such as the example above, I think we'd be treading on dangerous ground if we
tried to resolve it to anything more meaningful than a void expression.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
________
% As Chris notes, this does not involve any context beyond the expression
being typed.  In particular, on a 16-bit implementation,
	ulongvar = ushortvar * ushortvar
does a 16-bit multiply, not a 32-bit multiply; this is a classic gotcha.