The main problem I see is one of *packaging*.
Yes, exactly. Compiled standards mode essentially forces a "cfront-style" repository of sources ... and this irreversibly alters Gambit in one way or another, so careful community planning and consultation is needed.
How to attach meta information (macros, etc) to a compiled file? An interesting approach would be to put the result of compilation in a directory with subfiles with standardized names for the various parts.
I think this is an excellent idea, so long as GNU make et al can continue to get dependency analysis right. To effect this, it may be necessary to treat the directory creation as "atomic-as-possible" to prevent the creation of directory artifacts of various ages.
For example, "gsc foo.scm" would create the directory foo.o1 containing the "normal" foo.o1 shared lib and foo.c (useful for Scheme level linking) and other files for the visit and revisit information.
Do you see this alteration as something for gambit mode too, or just standards mode? Even in gambit mode, it'd be nice to place the .c and _.c files in a .o<n> folder. Any migration of the .c and _.c will regress existing build art.
For standards mode, the win of compiled syntax may offset the loss of backwards compatibility with existing build systems - is this also true for gambit mode?
It is desirable to introduce a flag to denote 'new packaging' mode to minimize community disturbance?
For standards-mode, such a directory may contain as many as five files:
foo.scm -> foo.o1/{foo.o1,foo.c,foo_.c,foo.visit.scm,foo.revisit.scm}
Code changes shouldn't be too tough (that is, mechanical, not innovative), but the test matrix is the cross-product of:
{ Windows, UNIX } x { gambit-mode, standards-mode } x { exe, incremental link, flat link } x { visit/revisit test suite }
I should also check to see how the various other backends, javascript et al, work with this proposal.
In the meantime, I'll work towards a patch in conjunction with specification that comes from this thread.
Kind regards,
Matt.