Hi, >This misses the whole point, which is for the compiler to be entirely >written in bitc. We need a parser regardless of the surface syntax.
I may well be missing the point, but I'm only suggesting it as a quick hack while the language - underlying facilities (which are still changeing?) and the to-be-decided surface syntax stabilises (and I'll bet it will take a while. Syntax causes more arguments than most anything else). When stable, then the full BitC parser can be written and grafted on & it'll be fully BitC throughout. It's a hack and a vile one but temporary. As you said, I may be missing the point. Please ignore this if I am and I'll watch the discussion progress. cheers jan ----- Original Message --------------- Subject: Re: [bitc-dev] why the switch to c++? From: "Jonathan S. Shapiro" <[email protected]> Date: Wed, 11 Feb 2009 16:29:46 -0500 To: Discussions about the BitC language <[email protected]> >--002215046c6f8efc6d0462ab4dc7 >Content-Type: text/plain; charset=ISO-8859-1 >Content-Transfer-Encoding: 7bit > >On Wed, Feb 11, 2009 at 4:13 PM, <"jan"[email protected]> wrote: > >> Quick think: >> "A parser generator that can handle actions written in BitC" >> Or maybe a trivial c lex/yacc (or similar) front end which sucks in the >> new surface syntax and spits out the old which is then piped straight >> to the old compiler? It's a vile but quick hack, and pretty portable. > > >This misses the whole point, which is for the compiler to be entirely >written in bitc. We need a parser regardless of the surface syntax. > >Or just write the new syntax lexer/parser by hand. Not a lot of fun but >> not too hard if it's a sensible syntax (ie. minimal lookahead). > > >It's currently single token lookahead, but its 174 productions at the moment >and about to grow. I'm not even going to *try* to maintain that by hand, and >attempting to do so would make validation harder. > >shap > >--002215046c6f8efc6d0462ab4dc7 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><div class=3D"gmail_quote">On Wed, Feb 11, 2009 at 4:13 PM, <span dir=3D"l= >tr"><"jan"<a href=3D"mailto:[email protected]";>[email protected]= >om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"bord= >er-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-l= >eft: 1ex;"> >Quick think:<br> ><div class=3D"Ih2E3d">"A parser generator that can handle actions writ= >ten in BitC"<br> ></div>Or maybe a trivial c lex/yacc (or similar) front end which sucks in t= >he<br> >new surface syntax and spits out the old which is then piped straight<br> >to the old compiler? It's a vile but quick hack, and pretty portable.</= >blockquote><div><br>This misses the whole point, which is for the compiler = >to be entirely written in bitc. We need a parser regardless of the surface = >syntax.<br> ><br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= > rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Or just= > write the new syntax lexer/parser by hand. Not a lot of fun but<br> >not too hard if it's a sensible syntax (ie. minimal lookahead).</blockq= >uote><div><br>It's currently single token lookahead, but its 174 produc= >tions at the moment and about to grow. I'm not even going to *try* to m= >aintain that by hand, and attempting to do so would make validation harder.= ><br> ><br>shap<br></div></div> > >--002215046c6f8efc6d0462ab4dc7-- > >--===============1444982044== >Content-Type: text/plain; charset="us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >_______________________________________________ >bitc-dev mailing list >[email protected] >http://www.coyotos.org/mailman/listinfo/bitc-dev > >--===============1444982044==-- _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
