Matt Diephouse <mdd...
> Now that IMCC is a core part of Parrot, I'd like to see the imcc/
> directory go away. I'd be willing to spend some time trying to prepare
> some patches (it'd be a good way to become more familiar with the
> source), but I have a few questions first:
> (1) Is this desirable?
As Melvin already stated, no: IMCC is a distinct subsystem of parrot
namely the PASM/PIR compilers (or assemblers). If you like to spend time
on it, I'd prefer the following instead:
- split PASM/PIR parsers and lexers into tow distinct file pairs
- make the C<.macro> pre-processor a separate pass
> (2) Does IMCC's version number ever differ from Parrot's?
We probably don't need the IMCC_VERSION.
> (3) Should all the headers in imcc/ be moved to include/parrot/?
No, they are mostly private to IMCC. But we need eventually a public
compiler interface, which should reside inside include/parrot.
> (4) Should all the files be moved to src/?
No with one exception: imcc/sets.c is a file implementing a bit set. All
functions should get a Parrot prefix and an interpreter argument.
> (5) Should the contents of the docs/, examples/, and t/ directories
> be moved to the root directories of the same names?
imcc/examples is useless, it can go away. imcc/docs needs some updates.
Especially syntax.pod sould be pasm.pod and pir.pod. Both are not quite
up-to-date. The tests are for testing the assemblers and should stay
> (6) Is there a document i should be reading about Parrot's directory
$ perldoc -F docs/pdds/pdd07_codingstd.pod
> (7) Should IMCC_ functions stay with that prefix or be renamed to use
> Parrot_ or something similar?
The IMCC_ prefix is fine.
> (8) Is there any reason to keep src/parrot.c around?
I'd like that to be eventually the real start program. It should parse
the commandline arguments and select an appropriate compiler depending
on the source filetype. One of these compilers is IMCC (or two :)
> (9) Is there anything else I should be aware of?