Two quick questions, what "hackish" things in pir are you refering to,
and how much more do you think it would take to get bytecode working?
Also, consider that file size alone is not the best indicator of how
well something is programmed, as sometimes a bigger object file is
faster than a smaller one(the difference between macros and functions
is an example).
PIR does have an unimplemented #line operator as does c and perl. If
you include support for it as well, you could consider doing macros and
includes with a preprocessor instead of in the parser itself. It might
make support for certain things easier. But a caveat of that is
handling something like '.Foo(")")' which requires an understanding of
PIR.
On Mar 21, 2007, at 4:53 PM, Klaas-Jan Stol (via RT) wrote:
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #41955]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41955 >
hi,
as requested by particle to send this to the list, attached a patch of
an implementation of PIR in C. Instead of using a bottom-up parser
(using Yacc), this is a pure-C top-down approach.
It is explicitly not my goal to do superfluous work, or to distract you
from working on More Important Things, but I send this, as mentioned on
request.
Of course, it's not finished yet, but a lot is working already (please
note it's only parsing).
THe current implementation of PIR, IMCC, is a bit hacky and not very
clean. Moreover, it's not reentrant. This patch tries to resolve this,
and tries to define what PIR should look like (no hacky things allowed
anymore).
Also, I wrote it to see how far I would come, and whether a top-down
approach was feasible. Also, considering that IMCC's parser's object
file is about 180 KB, and this one only about 35 KB (not the
executable,
which includes the C lib.) is a good sign. (I know, IMCC does a lot
more...)
Anyway, comments are most certainly welcome.
regards,
klaas-jan
