On Thu, Feb 12, 2009 at 12:25 AM, Jonathan S. Shapiro <[email protected]> wrote: > At this point, BitC is far enough along that we can and should start > self-hosting the compiler. For purely selfish reasons, there is one > remaining issue that I would like to resolve before we do that, which is the > final decision(s) about surface syntax. It is time to abandon parenthesis. > The surface syntax is mostly simple; I just need a brief block of time to > address it, and there is one particular issue that I will solicit opinions > about here. > > The main things that we need in order to self-host the BitC compiler are: > > 1. An interface module for the libicu components that we rely on. > 2. A parser generator that can handle actions written in BitC. > 3. A final choice of surface syntax. > 4. An AST compiler similar to ASTmaker that emits BitC code. > > Because we will not be sticking with an S-expression syntax, and also > because of the issue of static typing, LISP is definitely NOT the right way > to go at this point (and never was). I actually did do some prototyping in > Scheme at one point, but it quickly became apparent that Scheme wasn't the > right tool for this. > > I would like if you will consider ETL (http://etl.sf.net) as syntax definition mechanism. It combines a potential for almost-as-easy-as-XML tool support, almost-LISP level of language extensibility (but with other ideology), and allows to define C-like languages with some restrictions.
The current parser is for Java and it should be possible to use from other languages hosted on jvm. The parser is quite stupid and just does a lot of simple things, so it should not be a problem to port it to other languages. It should easy to create a complete ETL parser for gc variant of BitC, and the compiler could be bootstrapped using antlr from C++. I would like to hear a feedback on this technology, particularly about problems that prevent from using it for BitC. I think that main point of ETL for the BitC is that it allows for the language evolution on user side, including backward incompatible changes to the language. Considering that BitC is a research project, such flexibility could be very useful. And it is a kind of static type system for the sources (like DTDs are XML Schemas are static types for the XML files). Constantine _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
