TRUE and FALSE
Tim McDaniel
mcdaniel at adi.com
Fri Sep 7 03:49:38 AEST 1990
In article <F4u9._?1 at cs.psu.edu> flee at guardian.cs.psu.edu (Felix Lee) writes:
> Personally, I use this set of macros:
> #define FALSE 0
> #define CNAND(a,b) (!((a)&&(b)))
> #define CNOT(a) CNAND(a,a)
> #define CXOR(a,b) CNAND(CNAND(a,CNOT(b)),CNAND(b,CNOT(a)))
> ...
> These may unfortunately overrun some compiler or preprocessor limits
> (TRUE expands to an 853 character expression, and ISFALSE(x) expands
> to 203677 characters).
I called each macro once and printed the resulting lengths (assuming a
character-based preprocessor). It took about 90 CPU seconds to
compile on a Sun 3/60 with a local hard disk.
Macro call Length Macro call Length
FALSE 1 COR(x,y) 637
CNAND(x,y) 13 CAND(x,y) 2149
CNOT(x) 13 TRUE 853
CXOR(x,y) 61 ISTRUE(x) 101833
CEQUIV(x,y) 133 ISFALSE(x) 203677
ISTRUE generates so many characters because it uses CAND, which passes
its first argument (here, TRUE) to both COR and CXOR; COR passes three
copies to CEQUIV, CNOT, and CXOR, respectively; et cetera.
> especially when used in conjunction with a set of macros that
> provide LISP-ish control structures.
I haven't found a good way to do LAMBDA -- any suggestions? With
'm4', of course, it's trivial.
I rather like the way I did CONS. I didn't want the overhead of
checking for free space and allocating more on every call. Basically,
it increments the free-store pointer and just dereferences it. If
it's a bad pointer now, a signal handler does an "sbrk" to get a lot
more space, and it restarts the instruction that failed. And it's so
portable -- at least, it worked on every VAX that I tried it on.
Have I mentioned dereferencing NIL yet, to get 0?
By the way, would anyone like a copy of the shell I wrote in this
LISPish C? I call it "The Still-Bourne Shell".
--
Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Work phone: +313 973 1300 Home phone: +313 677 4386
Internet: mcdaniel at adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
More information about the Comp.lang.c
mailing list