On Thu, 2008-07-17 at 13:45 -0400, Jonathan S. Shapiro wrote: > 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.
The AST can be very complex, and it makes writing any extension non-trivial. If the macros are known to the compiler, then it can help locating problems (e.g. "type error at ... in the expansion of macro 'FOO at ..."). I'm really guessing here, but I would also imagine that pretty quickly, an extension writer wants to start doing some kind of type checking and error reporting. Somehow reusing the compiler facilities would be great. > > 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. Clearly concurrency has to be a concern. Which does not mean BitC has to do anything about it, *especially* because there is no clear "best" solution to this problem, as things stand. The language should probably just very carefully get out of the way, at least for now (just like C does). But it should also try to help the user with making the concurrent semantics explicit (annotation, etc). The Ocaml position "threads suck / we don't want to support them", saying its users should do everything with IPC (and therefore restrict drastically their concurrency model), clearly is not compatible with system-level/embedded problems. Not today. Whether one likes it or not, the model favored by current hardware is one thread per core, with synchronization through atomic operations and communication through cache lines invalidation, all of that in one shared-memory area. BTW, does BitC have any concept of 'volatile'? > 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. The best of both worlds would be to somehow give macros the ability to validate their arguments in a more abstract way than going through the AST by hand. Thanks. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
