Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #396
| 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> (permalink) |
| 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 |
Show key headers only | View raw
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]
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Looking for volunteers for XL Christophe de Dinechin <christophe@taodyne.com> - 2011-11-22 21:03 -0800
Re: Looking for volunteers for XL Kaz Kylheku <kaz@kylheku.com> - 2011-11-26 05:43 +0000
Re: Looking for volunteers for XL Christophe de Dinechin <christophe@taodyne.com> - 2011-11-26 12:38 -0800
Re: Looking for volunteers for XL "BartC" <bc@freeuk.com> - 2011-11-26 23:19 +0000
Re: Looking for volunteers for XL Christophe de Dinechin <christophe@taodyne.com> - 2011-11-27 12:34 -0800
Re: Looking for volunteers for XL "BartC" <bc@freeuk.com> - 2011-11-27 22:24 +0000
Re: Looking for volunteers for XL Christophe de Dinechin <christophe@taodyne.com> - 2011-11-28 14:12 -0800
Re: Looking for volunteers for XL ardjussi <jussi.santti@ard.fi> - 2011-11-30 13:16 -0800
Re: Looking for volunteers for XL Kaz Kylheku <kaz@kylheku.com> - 2011-12-01 05:44 +0000
Re: overloading, was Looking for volunteers for XL glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-12-02 05:36 +0000
Re: Looking for volunteers for XL tm <thomas.mertes@gmx.at> - 2012-01-03 09:28 -0800
Re: Looking for volunteers for XL Kaz Kylheku <kaz@kylheku.com> - 2011-11-28 04:45 +0000
Re: Looking for volunteers for XL Timothy Knox <tdk@thelbane.com> - 2011-11-27 22:50 -0800
Re: Looking for volunteers for XL Alex McDonald <blog@rivadpm.com> - 2011-12-01 12:11 -0800
Re: Looking for volunteers for XL "BartC" <bc@freeuk.com> - 2011-11-28 10:23 +0000
Re: Looking for volunteers for XL glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-11-29 07:37 +0000
Re: macros, Looking for volunteers for XL Gene Wirchenko <genew@ocis.net> - 2011-12-03 17:36 -0800
Re: macros, Looking for volunteers for XL glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-12-05 04:24 +0000
Re: Looking for volunteers for XL Kaz Kylheku <kaz@kylheku.com> - 2011-12-01 05:35 +0000
Re: designing language extensions, was Looking for volunteers for XL Marco van de Voort <marcov@toad.stack.nl> - 2011-12-03 13:02 +0000
Re: Looking for volunteers for XL jgk@panix.com (Joe keane) - 2011-12-13 00:08 +0000
Re: macros, was Looking for volunteers for XL Kaz Kylheku <kaz@kylheku.com> - 2011-12-13 01:39 +0000
Re: macros, was Looking for volunteers for XL Kaz Kylheku <kaz@kylheku.com> - 2011-12-14 19:00 +0000
Re: macros, was Looking for volunteers for XL jgk@panix.com (Joe keane) - 2011-12-15 15:40 +0000
Re: macros, was Looking for volunteers for XL Kaz Kylheku <kaz@kylheku.com> - 2011-12-16 17:48 +0000
Re: Looking for volunteers for XL glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-11-28 10:26 +0000
csiph-web