On Thu, 2008-07-17 at 09:24 -0700, Eric Rannaud wrote: > Well, as somebody interested in using BitC for high-performance software > and embedded applications, I would really like to see macros supported.
Let me say first that I would too, but not if we have to sacrifice auditability, and not if the macro system turns out to be too complicated to use. In particular, it might well be better to define a canonical AST, provide a BitC parser written in BitC, and just let people implement their own extensions. I don't know. I'm just thinking out loud at the moment. > 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. Actually, this is a terrific example of something that should absolutely no way be done with macros. This is a problem where I suspect that type classes are the right answer. Having said that, let me also say that I am making a wild-assed un-considered statement, and that I consider concurrency design one of the big open issues in the whole language design space. We clearly need some assist from some part of the compile chain, but it isn't clear (to me) what form that assist should properly take. The problem I see with doing this sort of thing in the macro system is that you lose the checking advantages that you can obtain if you keep this sort of thing type-able. > Also, one must not forget the various needs for conditional compilation, > sometimes at a local level in the code. I'll take this up separately. > 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. I agree with this point, but this argues for a generalized annotation meta-language, which is already on the list of things to be done for Bitc. > 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. Yes. I'll take this up in a separate note as well. > And there are, of course, better ways > to do macros than CPP, as you pointed out. No no! CPP is the *garden spot* of Ceti Alpha Five... shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
