[gambit-list] More work on compiled syntax and modules

Mikael mikael.rcv at gmail.com
Wed Oct 23 02:17:34 EDT 2013


Hi Matt,

All of Gambit's primitives for compilation, linking etc. already supports
specification of output path, and Gambit itself is free of a packaging
abstraction and leaves all of that for the user code (such as a specific
user-implemented macro expander like one for syntax-case, even if bundled
as an optional together with the Gambit distro) to implement atop Gambit's
primitives.

Therefore there should be no need of changing Gambit's behavior with regard
to what directories it outputs c/object/library/executable files into -

Perhaps this was what you meant already?


Metadata such as macros can be stored in one or more files specific your
macro expander/module system, or if desired you can include such metadata
as a predefined global or procedure call inside your output code and that
way get it included in your output object files. For instance Black Hole
does this.

For my reference, what's the visit/revisit about?

Best regards,
Mikael



2013/10/22 Matt Hastie <matthastie at gmail.com>

>
> On Oct 22, 2013, at 8:43 AM, Marc Feeley <feeley at iro.umontreal.ca> wrote:
>
> 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.
>
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://webmail.iro.umontreal.ca/pipermail/gambit-list/attachments/20131023/84d1953b/attachment-0001.html 


More information about the Gambit-list mailing list