On 10/22/07, Allison Randal <[EMAIL PROTECTED]> wrote: > > Klaas-Jan Stol wrote: > > Hi, > > > > Last few days i've been working on a complete reimplementation of IMCC's > > grammar. It can be found in compilers/pirc/new. THere's no Makefile yet, > as > > I didn't know how to create this in a portable way (as flex and bison > are > > needed). No tests yet either, I only do that with small test files on my > pc. > > > > I found updating and fixing IMCC's grammar rather difficult and no fun > as > > there's a lot of unclear stuff. A clean implementation can resolve the > > trouble of changing the PIR language. > > It's a good prototyping approach. We'll keep an eye on your progress and > decide at some later date how to integrate the work (merge/replace). > > > Up till now, things worked out pretty well. Although it's not completed > yet > > (and only focus on the parsing, > > not on the semantic stuff), the new implementation has the following > > features: > > > > * no grammar kludges, like %PREC, yy_clear_state(), and /* this is ugly > */ > > comments > > +1 > > > * nice opportunity to clean up some dark corners of IMCC's grammar. Did > > youknow you could define a namespace like this: ".namespace ['a' .. > 'b']" ? > > I can't imagine what this should mean. > > Can be considered deprecated. Can even be added to DEPRECATED.pod.
will do. > * removal of (almost) all globals. I'm not sure about some built-in > globals, > > like "yytext". In any case, the goal is to make it reentrant. > > * support for multiple heredocs, allowing to write: > > .sub foo(<<'A', <<'B', <<'C') > > hi > > A > > hi there > > B > > hi again > > C > > > > * A clean implementation of the .include directive > > +3 > > > * .constant directive works, but I found out IMCC only allows it in PASM > > mode. If this is desired behaviour, I have to change my implementation. > > Currently constants are declared as .const in PIR and .constant in PASM. > These two should be merged into one. I don't have a strong preference > but lean toward keeping .constant and deprecating .const (the full word > is generally more readable). > > > * comments. Lots of it. > > * beginning implementation of macros. > > * the lexer spec. is processable by cygwin's default flex version (I > think > > imcc.l can't be processed with that version) > > +3 > > > * an opportunity to decide how PIR should parsed w.r.t. PASM. SHould PIR > be > > converted to PASM, or should it be interpreted from PIR source > immediately? > > Both options should be possible. PASM is just a human readable form of > bytecode, so anything that can be translated to bytecode can be > translated to PASM. But, we don't need to require PASM as an > intermediate step between PIR and bytecode. I see. I'm not ready yet for semantic stuff,I'll have to look into it, I never looked into IMCC's semantic actions. > * A basic pre-process option (using "-E"), which shows the user the input > as > > it is read by the parser. > > Sounds good. Why "-E"? *E*arly? *E*xellent? I stole it from IMCC :-) > Before I continue on finishing the macros, however, I think it'd be nice > to > > set up some kind of feature list of what macros should be able to do. I > > don't want to put in a lot of effort finishing the macro stuff, only to > find > > out that new features should be added/removed. Recently, there was a bit > > discussion on list about local variables in macros, which could be added > > (that generate unique vars, just like .local/.label does for labels > > currently). > > Thanks for the beginning spec. I'll review it as part of PDD 19 (which > smash tells me is ready for at least the first review). > > Allison I also just added a README.pod file in which I try to be clear in what the differences are with IMCC, and of course the improvements over IMCC. Thanks for your feedback! kjs
