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.
* 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.
* 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?
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
