On Thu, 2008-07-17 at 10:34 -0400, Jonathan S. Shapiro wrote:
> Given the way in which we went about building the prototype compiler,
> the potential complexity in [2] was overwhelming. Given the environment
> issues that are raised by [2], I am inclined to believe that if we want
> a macro system it may be better to think of it as extending the parser
> on the fly rather than performing an AST->AST transform.
>
> Because the surface syntax will be changing, we are hitting the point
> where we more or less need to take a position on this issue. Any
> thoughts that anybody wants to offer on this whole issue? Any pointers
> to other schemes that I should look at?
Well, as somebody interested in using BitC for high-performance software
and embedded applications, I would really like to see macros supported.
If only because the language designers cannot (and do not _want_ to)
anticipate all the needs of an end-user. For instance, BitC does not say
anything about multithreading. That's OK. But a macro like
(with-lock (lock)
...)
would be very useful in practice. Let the user define it.
Also, one must not forget the various needs for conditional compilation,
sometimes at a local level in the code. It is never a nice thing to do,
but hardware can be quite capricious and it is sometimes necessary to
use macros in that way.
Macros can also be useful to "decorate" the code with additional
information not understood by BitC. See how the static checker 'sparse'
is used for the Linux kernel: they use a number of flags (__bitwise for
endianness, __acquires(x)/__releases(x) for lock validation,
__user/__kernel for address space separation, etc.) See
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/compiler.h;hb=HEAD
During normal compilations, these various constructs are defined to
nothing so that they don't interfere with the compiler.
BTW, this is another reason to keep the current syntax: it is much
easier to build a static analyzer for BitC with a lispish syntax than
with a C like syntax.
The need for (and the constraints of) audit can be real in certain
contexts (I believe many safety regulations mandate "dumb" audit which
consist in having the code read by external people). In other contexts
however, this kind of "dumbed down" audit is irrelevant. Maybe a
compiler switch to disable macros would satisfy the people who don't
want them?
I am also well aware that there is school of thoughts that says "macros
are evil". But this has little basis in reality: if they can be badly
misused, good programmers can make good use of them. BitC is not Java:
it doesn't have the same target audience. Protecting the user from
himself may not be as necessary. And there are, of course, better ways
to do macros than CPP, as you pointed out.
Thanks.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
