Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!labrea!rutgers!bellcore!texbell!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.lang.misc
Subject: Re: Expression Based Language
Message-ID: <2767@ficc.uu.net>
Date: 16 Jan 89 14:55:18 GMT
References: <3300001@uxg.cso.uiuc.edu> <3290002@hpctdls.HP.COM> <2734@ficc.uu.net> <15472@mimsy.UUCP>
Organization: Xenix Support
Lines: 32

In article <15472@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> [re type-matching in multipart expression values]
> >>Context outside of the expression itself?  I think that's dangerous ground.

> In article <2734@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
> >That's the way it currently works for ?: [in C].

> No: in `a ? b : c', the type of the result is based only on the
> types of `b' and `c', much as though b and c were to be added.

OK, the bottom line for expression-C remains the same... there is no
reason you shouldn't be able to say:

	a = if (this) then 10.0 else 'a';

...and have all the coercions work the same way they do in real-C for:

	a = (this) ? 10.0 : 'a';

Personally I wish that this sort of implicit type-coercions in 'C'
was be deferred as late as possible, to take advantage of surrounding
context. That way you wouldn't be burned by assuming this makes sense:

	long_var = (unsigned short)65535 + (signed short)32767;

This calculation seems, to the 'C' novice, like it should equal 98302,
but it actually ends up 32766.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
Work: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.   `-_-'
Home: bigtex!texbell!sugar!peter, peter@sugar.uu.net.                 'U`
Opinions may not represent the policies of FICC or the Xenix Support group.