Re: macros, was Looking for volunteers for XL

Kaz Kylheku <kaz@kylheku.com>
Fri, 16 Dec 2011 17:48:32 +0000 (UTC)

          From comp.compilers

Related articles
Looking for volunteers for XL christophe@taodyne.com (Christophe de Dinechin) (2011-11-22)
Re: Looking for volunteers for XL kaz@kylheku.com (Kaz Kylheku) (2011-12-01)
Re: Looking for volunteers for XL jgk@panix.com (2011-12-13)
Re: macros, was Looking for volunteers for XL kaz@kylheku.com (Kaz Kylheku) (2011-12-13)
Re: macros, was Looking for volunteers for XL kaz@kylheku.com (Kaz Kylheku) (2011-12-14)
Re: macros, was Looking for volunteers for XL jgk@panix.com (2011-12-15)
Re: macros, was Looking for volunteers for XL kaz@kylheku.com (Kaz Kylheku) (2011-12-16)
| List of all articles for this month |
From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.compilers
Date: Fri, 16 Dec 2011 17:48:32 +0000 (UTC)
Organization: A noiseless patient Spider
References: 11-11-048 11-12-002 11-12-017 11-12-018 11-12-023
Keywords: design, comment
Posted-Date: 16 Dec 2011 16:31:28 EST

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]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.