Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!dino!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh From: mccaugh@s.cs.uiuc.edu Newsgroups: comp.lang.c Subject: Re: What I'd really like to see in an i Message-ID: <207600027@s.cs.uiuc.edu> Date: 9 Aug 89 23:03:05 GMT References: <5024@alvin.mcnc.org> Lines: 20 Nf-ID: #R:alvin.mcnc.org:5024:s.cs.uiuc.edu:207600027:000:1184 Nf-From: s.cs.uiuc.edu!mccaugh Aug 8 18:19:00 1989 First, I concur with Dworkin that a multiple relation might as well be considered (e.g. a <= b < c <= d < e). Second, I disagree with the assertion this has nothing to do with 'if', since it is usually the purpose of a comparison -- be it simple or compound -- to execute some statement(s) conditioned upon such a test (which may be why the semantics of conventional languages posit a Boolean for the first argument to an 'if'). The problem I have with "liberalizing" such semantics is that the comparison operators might not then be able to enter into general Boolean expressions. I disagree with the claim about Icon that "tests returning a result or not" is a good idea; for one thing, what am I to do in a complex Boolean expression with a non-result? I much prefer Backus's suggestion of a 3-values logic (where 'bottom' would convey no result): otherwise, there seems to emerge confusion between "no result" and "failure". This is more discriminating than to say: x/0 => no result (as otherwise, 1=0 <=> 1/0 holds). Finally, it would seem that a macro pre-processor for C ought to resolve this problem (in a way commensurate with BCPL and COBOL, e.g.).