Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #350 > unrolled thread

Looking for volunteers for XL

Back to article view | Back to comp.compilers

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#389

Kaz Kylheku <kaz@kylheku.com> wrote:
>For one thing, any syntactic unit that contains declarations cannot be
>an expression that returns a value. Macros that need to generate
>complex code that requires hidden variables automatically have a
>difficulty in returning a value in a function-call-like way, because
>only expressions do that.

That is valid, but it's not not-difficulty work-around-ed.

#2. Don't use function-like macros.

Make the result one of the parameters (unless it is really simple, then
some day in the future your 'really simple' macro is not so really
simple).

e.g.

    #define GET_FORDO_BIT(FOP) \
    ...

    int f(int x)
    {
	...
	if (GETFORDO_BIT(fop))
	{
	    ...
	}
	...
    }

versus

    #define GET_FORDO_BIT(FOP, FOB) \
    ...

    int f(int x)
    {
	...
	GET_FORDO_BIT(fop, fob);
	if (fob)
	{
	    ...
	}
	...
    }

How hard is that?

[toc] | [prev] | [next] | [standalone]

#390 — Re: macros, was Looking for volunteers for XL

On 2011-12-13, Joe keane <jgk@panix.com> wrote:
> #2. Don't use function-like macros.
>
> Make the result one of the parameters (unless it is really simple, then
> some day in the future your 'really simple' macro is not so really
> simple).
>
> e.g.
>
>     #define GET_FORDO_BIT(FOP) \
>     ...
>
>     int f(int x)
>     {
> 	...
> 	if (GETFORDO_BIT(fop))
> 	{
> 	    ...
> 	}
> 	...
>     }
>
> versus
>
>     #define GET_FORDO_BIT(FOP, FOB) \
>     ...
>
>     int f(int x)
>     {
> 	...
> 	GET_FORDO_BIT(fop, fob);
> 	if (fob)
> 	{
> 	    ...
> 	}
> 	...
>     }
>
> How hard is that?

It's not hard to make, just hard to use.

Problem is, you're creating something akin to an assembly language,
with instructions that have source and destination operands.

GET_FORDO_BIT(FOP, FOB) cannot be used as a subexpression in a larger
expression.

If you have any complex computation going on made up of macros of this
type, you have to declare lots of temporary variables, and lay these
instructions in sequence, like a machine language program.

Now you need a compiler to generate that cruft for you.

The need for generating temporary variables has not gone away.
We've just given up doing it in the macro and shifted it onto the
programmer, who would rather now shift it back onto the machine.

Sure, if these macros are few and far between, that may be acceptable. In that
situation, you have nice code, whose structure is just broken up here and there
with an ugly imperative macro like this.  It's intractable if you have many of
them, and want to write programs that are mostly made up of those macros.

Real macros let you do that: make robust languages that make heavy, dense use
of those macros, not only some syntactic sugar that is to be sprinkled very
sparingly.
[Seems to me that what you really want here is in-line functions.  Macros are
useful for other stuff, too. -John]

[toc] | [prev] | [next] | [standalone]

#394 — Re: macros, was Looking for volunteers for XL

On 2011-12-13, Kaz Kylheku <kaz@kylheku.com> wrote:
> Real macros let you do that: make robust languages that make heavy, dense use
> of those macros, not only some syntactic sugar that is to be sprinkled very
> sparingly.
> [Seems to me that what you really want here is in-line functions.  Macros are
> useful for other stuff, too. -John]

Inline functions don't always fit the bill.

For instance, try this exercise:

Implement the operator or2(A, B) which does this:

1. A is evaluated. If A is nonzero, then the value of A is returned.
2. Otherwise, B is evaluated and its value is returned.

You cannot write this as an inline function or as a non-kludgy macro in C.

Yet this or2 is not some esoteric macro either: it's a simple operator that
is only a tiny semantic modification to C's  || and  ?:   operators.

Both arguments to the macro are expressions! It doesn't reinterpret their
syntax in any way; it just arranges for their evaluation.
[Yeah, you need inline functions with call by name and reference variables.
Yuck. -John]

[toc] | [prev] | [next] | [standalone]

#395 — Re: macros, was Looking for volunteers for XL

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!

Some typical code:

    int f(struct foo *foo)
    {
	...

	err = foo_get_bar(foo, q, &bar);
	if (err != 0)
	    ...

	err = bar_get_box(bar, p, &box);
	if (err != 0)
	    ...

	...

	err = box_frobnz(box, z, &a);
	if (err != 0)
	    ...

	if (soanso)
	{
	    err = box_grobny(box, y, &b);
	    if (err != 0)
		...
	}

	...
    }

The version with macros will look exactly the same, except you can omit
the '&', and they're usually upper case.

>The need for generating temporary variables has not gone away.

I think this is not a big deal, since the value is often then used more
than once.  Even if not, the code may be more clear, if less concise.
[also helps debugging]

[toc] | [prev] | [next] | [standalone]

#396 — Re: macros, was Looking for volunteers for XL

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]

[toc] | [prev] | [next] | [standalone]

#367

Kaz Kylheku <kaz@kylheku.com> wrote:

(snip)
>> Extensible languages have to be used with some care I think. Those
>> features aren't for everyday use.

> Actually, perhaps surprisingly, language extensibility features are for
> everyday use.

(snip)

> This is worth doing for language extensions that are significant, and
> of interest to a wider community of people. But it's a time-consuming
> process.

Not that I completely understand XL, but we also have languages with
preprocessors, simple and not so simple.  We also have processors,
sometimes in the form of macroprocessors, that allow one to modify the
language accepted by the processor.

Some years ago, when Fortran 66 was popular, but not quite as easy to
use as it could have been, languages like RATFOR and MORTRAN were
created, along with the appropriate processor.  Still, such never got
quite as popular as one might have hoped.

> Extensibility in the language allows such a thing to be conducted as a
> project which regularly releases code (rather than just paper).

> It also allows some fraction of any application to consist of some
> extensions to give it a little domain-specific language or whatever.

Now, if one includes the description (or macros) needed for the
extension as part of the source file does it still count as an
extension?

(snip)
> Under an extensible language culture, the lone guru working in
> isolation produces not a new language, but some new extension. These
> can be released as code for people to try. Then when the bug reports
> pour in and it's all hammered out, a formal spec can be written.  The
> guru deosn't get to ask everyone to ditch their language, only to add
> something to it.

But consider how new standard versions of a language get created.
One usually adds extensions to an existing compiler, tests out
the new features for a while, and then standardizes the result.

That is different from an extensible language, but it seems
to me that the result isn't so different.

(snip)

-- glen

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.compilers

csiph-web