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?
 (2) Does IMCC's version number ever differ from Parrot's? Right now
they're both defined, but they're both the same. If they'll always be
the same, it doesn't make sense to have an IMCC version number (IMHO).
 (3) Should all the headers in imcc/ be moved to include/parrot/?
 (4) Should all the files be moved to src/?
 (5) Should the contents of the docs/, examples/, and t/ directories
be moved to the root directories of the same names?
 (6) Is there a document i should be reading about Parrot's directory structure?
 (7) Should IMCC_ functions stay with that prefix or be renamed to use
Parrot_ or something similar?
 (8) Is there any reason to keep src/parrot.c around?
 (9) Is there anything else I should be aware of?

Thanks.

--
matt diephouse
http://matt.diephouse.com

At 06:57 PM 4/11/2005, Matt Diephouse wrote:

Technically IMCC should be separate

I think mild separation that still exists is a good thing. IMCC does
not actually execute anything, it is a "registered" front-end that
handles PIR and PASM. You could add another front-end
called PIR2 if you wanted. It just so happens that IMCC is the
default front-end.

You should be able to build a standalone VM that will run pre-compiled
bytecodes without including the full parser/compiler, IMO. I'd prefer
to see the separation continue.

Regards,

-Melvin

Actually there is already a second front end, PAST, which resides in the
'ast/' directory.
It might make sense to refactor 'imcc/main.c' and split it into e.g.
'src/main.c' and 'imcc/frontend.c'. This would make the distinction more
clear, and would provide an opportunity to clean up the exported symbols.

CU, Bernhard

--
**************************************************
Dipl.-Physiker Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: Bernhard.Schmalho...@biomax.com
Website: www.biomax.com
**************************************************

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

We probably don't need the IMCC_VERSION.

No, they are mostly private to IMCC. But we need eventually a public
compiler interface, which should reside inside include/parrot.

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.

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
there.

Probably:
$ perldoc -F docs/pdds/pdd07_codingstd.pod
/Subsystems

The IMCC_ prefix is fine.

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 :)

Yes ;)

leo