rb@ccird1.UUCP (06/24/86)
One common reference that kills is the old "is this in range" test. typically, this is written: if((5<a)&&(a<50)) do_something(a); suppose instead of a, you use a->b->c->d, all that pointer arithmetic gets done twice? (maybe it is optimized but its harder to read). How about: if (5<a<50) do_something(a); this would currently be interpreted as if((5<a)<50). since, if a=100 (5<a) evaluates to 1 and 1<50, it is true for any number greater than 5 right? this can be real useful for pre-checking an array bounds, a int (f[])(); type switch, and even skipping over a case statement. Is this impossible to parse?
cudcv@daisy.warwick.UUCP (Rob McMahon) (06/29/86)
In article <523@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: > >if (5<a<50) do_something(a); > ... > >Is this impossible to parse? This was in BCPL, and was a GOOD IDEA. -- UUCP: ...!mcvax!ukc!warwick!cudcv JANET: cudcv@uk.ac.warwick.daisy ARPA: cudcv@daisy.warwick.ac.uk PHONE: +44 204 523037 Rob McMahon, Computer Unit, Warwick University, Coventry CV4 7AL, England
franka@mmintl.UUCP (Frank Adams) (07/01/86)
In article <523@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >if (5<a<50) do_something(a); > >this would currently be interpreted as > >if((5<a)<50). since, if a=100 (5<a) evaluates to 1 and 1<50, it >is true for any number greater than 5 right? Well, yes; but if a is not greater than 5, then (5<a) is zero, which is also less than 50; so this is in fact always true. >Is this impossible to parse? A little tricky, but not impossible. To my knowledge (I don't know everything), only COBOL actually does this. I, for one, think it's a good idea; but for new languages, please -- don't try and change C to accomodate it. Once you have assigned a meaning to a<b<c, it is impractical to try and change it. (There is one easy-to-implement rule which does permit this to be added in an upward compatible way -- make a<b<c illegal. Ada does this; in some other languages it is semantically illegal, since comparison operators are not permitted to operate on boolean expressions.) Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
gwyn@BRL.ARPA (VLD/VMB) (07/01/86)
Problem is, C already has a meaning for 5<a<50 and it's not the one you want.
rbj@icst-cmr (Root Boy Jim) (07/01/86)
>if (5<a<50) do_something(a); > >Is this impossible to parse? This was in BCPL, and was a GOOD IDEA. COBOL has this too. It is not impossible to parse, but it is not trivial either. It requires lookahead to resolve the meaning. Perhaps another syntax? (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> The entire CHINESE WOMEN'S VOLLEYBALL TEAM all share ONE personality --
rcd@nbires.UUCP (Dick Dunn) (07/05/86)
> >if (5<a<50) do_something(a); > > > >Is this impossible to parse? > > This was in BCPL, and was a GOOD IDEA. > > COBOL has this too. It is not impossible to parse, but it is not trivial > either. It requires lookahead to resolve the meaning. Perhaps another syntax? This suggestion ( 5<a<50 ) seems to come up every few months. Every few months someone gets to point out that it exists in Icon and it works. The parsing (for Icon, not COBOL) is no different than for any other dyadic operator; it requires no extra lookahead or magic. The Icon trick is that success/failure indications (which drive control structures like "if") are separate from values. The operator "<" may either fail (meaning that the relation does not hold) or succeed. If it succeeds, it produces its right operand as result. The only remaining piece of the puzzle is that "<" is left-associative (as dyadic operators usually are), so that 5<a<50 means (5<a)<50. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Simpler is better.
mcdaniel@uicsrd.CSRD.UIUC.EDU (07/07/86)
/* Written 7:42 pm Jun 30, 1986 by franka@mmintl.UUCP in uicsrd:net.lang.c */ >In article <523@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >>Is this impossible to parse? >To my knowledge (I don't know >everything), only COBOL actually does this. As a comparative language note, ICON does it. "a < b" returns "b" if the comparison succeeds; with left-to-right association of "a < b < c", it works. The tricky part is that I haven't said what happens if the comparison is false. In that case, the expression "fails", and the rest of the statement is skipped; the next statement is executed. (Actually, ICON has PROLOG-like goal-directed evaluation: 2 < find("a", "ababc") will fail; find will be "resumed" where it left off to find any later substrings and the expression will return 3. It would take kilobytes to explain fully.) So this model is not applicable to C, alas. To find the max of two variables in C, we can say if (a < b) a = b; In ICON, the idiom is a <:= b Almost any binary operator can augment assignment, like C's "+=". This is "a := a < b"; if a >= b, the comparison fails and the rest of the statement is skipped. I think ICON is a truly great, clean language (for its domain). > I, for one, think it's a good > idea; but for new languages, please -- don't try and change C to accomodate > it. Yeah.