Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.chainon-marquant.org!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!198.186.194.247.MISMATCH!transit3.readnews.com!news-out.readnews.com!news-xxxfer.readnews.com!news.misty.com!news.iecc.com!nerds-end
From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.compilers
Subject: Re: macros, was Looking for volunteers for XL
Date: Fri, 16 Dec 2011 17:48:32 +0000 (UTC)
Organization: A noiseless patient Spider
Lines: 78
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <11-12-024@comp.compilers>
References: <11-11-048@comp.compilers> <11-12-002@comp.compilers> <11-12-017@comp.compilers> <11-12-018@comp.compilers> <11-12-023@comp.compilers>
NNTP-Posting-Host: news.iecc.com
X-Trace: leila.iecc.com 1324071088 9056 64.57.183.58 (16 Dec 2011 21:31:28 GMT)
X-Complaints-To: abuse@iecc.com
NNTP-Posting-Date: Fri, 16 Dec 2011 21:31:28 +0000 (UTC)
Keywords: design, comment
Posted-Date: 16 Dec 2011 16:31:28 EST
X-submission-address: compilers@iecc.com
X-moderator-address: compilers-request@iecc.com
X-FAQ-and-archives: http://compilers.iecc.com
Xref: x330-a1.tempe.blueboxinc.net comp.compilers:396

On 2011-12-15, Joe keane <jgk@panix.com> wrote:
> Kaz Kylheku  <kaz@kylheku.com> wrote:
>>Problem is, you're creating something akin to an assembly language,
>>with instructions that have source and destination operands.
>
> So it looks like... an imperative programming language!

C is not strictly an imperative language. It supports application of
arguments to functions and the use of values in nested expressions.

I would not use macros that required me to write:

  add(t1, b, c);
  add(t2, y, z);
  mul(result, a, x);
  return result;

instead of just:

  return mul(add(b,c), add(y,z));

> Some typical code:

Stop writing typical code!

>     int f(struct foo *foo)
>     {
> 	...
>
> 	err = foo_get_bar(foo, q, &bar);
>
> 	if (err != 0)
> 	    ...

Still too functional; I think you wanted:

    foo_get_bar(foo, q, &bar, &err);

	if (err != 0)

:)

What if I we don't need individual error handling for these cases?  Suppose all
we care about is detecting whether an error happened somewhere.

For that I would like a sequencing macro OR with the following
properties: OR(A, B, C, ...) is like A || B || C ...
except that instead of returning 1 or 0, returns the first
nonzero value among A, B, C...

Then I could write:

 if ((err = OR(foo_get_bar(foo, q, &bar),
               bar_get_box(bar, p, &box),
			   ...)))
 {
   /* we have an error: abort mission */
 }

We can use || but then we don't know what the error is. One way to solve
that is to just return a 0/1 indication, and use some global interface
to get to the error.

Another thing is that maybe we can design the API to accept nulls gracefully.
That is to say, suppose foo_get_bar fails? It can return null, and bar_get_box
can handle a null and just also return null:

   a = box_frobnz(bar_get_box(foo_get_bar(foo, q), z);

   if (!a) {
      /* ourlib_geterror() has the messy details */
   }

There is no reason that anyone in the year 2011 should write so many lines of
code with so much error checking just to navigate through a three-level
hierarchy to retrieve something.
[I don't disagree, but this is rapidly heading toward semicolon placement
territory. -John]