Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!cica!gatech!udel!burdvax!dave From: dave@PRC.Unisys.COM (David Lee Matuszek) Newsgroups: comp.lang.misc Subject: Re: What I'd really like to see in an if-statement... Message-ID: <11152@burdvax.PRC.Unisys.COM> Date: 14 Aug 89 18:44:43 GMT References: <178@enea.se> Sender: news@PRC.Unisys.COM Organization: Unisys Corporation, Paoli Research Center; Paoli, PA Lines: 67 In article <178@enea.se> sommar@enea.se (Erland Sommarskog) writes: >I think John Lacey (lacey@tcgould.tn.cornell.edu) said this: >>The parse would be more difficult. The problems aren't analogous. The >>dangling-else problem is one of ambiguity. Parsing a general relational >>expression is difficult because the same string will be used for multiple >>tokens. For example, in (a < x < b), x has to be associated separately >>to its left and right. > >I have to object here. Way back at the university I took a compiler >course. In the tiny language I made for my assignment I defined the >grammar relational expression something like: > rel_exp ::= exp (rel_op exp)* >()* meaning 1 or more times easy. Trivial, isn't it? The semantic >interpretation was AND. I.e. 0 < x < 10 was interpreted as (0 < x) >AND (x < 10), which seems as the natural interpretation for the >case you would like to use it for. A thing like > a = b <= z > y < b >wouldn't something to recommend but the langauge dealt with it the same >way. > >Actually I have always been surprised that no language I have dealt >have had this feature since it is so easy to implement. Am I overlook- >ing something? >-- Sorry for the long insertion, but context is important. A couple of years ago I developed a small special-purpose language for the project I was involved in. One of the things I did was to implement extended relational expressions such as described above. I wrote both an interpreter and a compiler for the language, and it got a fair amount of use. It wasn't hard. I don't think you're overlooking anything. I had no trouble at all with that part of the language. You do have to decide what to do about expressions such as "x < (y < z)" ["illegal" is a good choice!]. I don't think it would be a good idea to try to extend C in this way, since x < y has an interpretation that only a hacker could love (an integer rather than a truth value), but Pascal-like languages are no problem. Like you, I don't know why more languages don't have this perfectly natural construct. BTW, I also implemented allin satisfy each in satisfies some in satisfies (The first two are just syntactic variants of each other.) I also meant to add the following, but never got around to it: no in satisfies The is used in the logical expression; if "all/each" or "no" fails, or if "some" succeeds, the retains the (first) value that caused this to happen, otherwise the is undefined. These aren't hard either, and save the programmer from explicitly writing loops for some common cases. I think these are not common because Pascal-like languages do not generally have sets or lists as supported data types. -- Dave Matuszek (dave@prc.unisys.com) -- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA 19301 -- Any resemblance between my opinions and those of my employer is improbable. Remember, too, that 1989 is the 17th anniversary of the LAST man on the moon.