2013/10/23 Matt Hastie <matthastie@gmail.com>

On Oct 22, 2013, at 11:17 PM, Mikael <mikael.rcv@gmail.com> wrote:

no need of changing Gambit's behavior with regard to what directories it outputs

As you suggest, a possible implementation is to create a wrapper executable, perhaps scsc, that can provide the new behavior. This has been the historic practice, as done by black hole.

Yeah exactly like that!

And let Gambit remain doing the low-level abstractions of sourcecode => object file compilation and loading, only. Kinda like GCC+OS dynloader do.


And then Gambit provides hooks for whatever you may want to achieve packaging/module/macro-wise.

Reflecting on Gambit being abstracted like this for some years, I have come to really appreciate that it does it exactly like that and also I've found the set of hooks Gambit provides for implementing such functionality atop it to be complete, with only one thing that'd be strikingly useful additionally, mentioned that here Sep 27-28, https://mercure.iro.umontreal.ca/pipermail/gambit-list/2013-September/007064.html . 
     (disclaimer, I have not implemented a module system myself, however Per and myself had unending conversations around and after he implemented Black Hole, so this is the kind of level of insight I'm speaking out of currently)


If you have any further reflections to share here, feel very welcome to.

To follow this paradigm without any gambit alteration would necessitate independent shipment of a custom psyntax73 with additional hooks for visit/revisit. The proposed would be a separate implementation that is independent of -:s and the shipped syntax-case.scm functionality. Any mutation to psyntax73 with respect to the current build-visit-only and build-revisit-only definitions is likely to regress existing -:s functionality, just as my existing patch of emitting $sc-put-cte has done.

Reflecting on the directory .o1 file proposal overnight, I think that the most minimal repl implementation would use namespaces to wrap load and compile-file. A command-line gsc is more difficult to provide without alteration, however, as the implementation of compiler-batch-mode is captured in the lexical scope of ##main-gsi/gsc. It thus cannot be modified by a prospective compiler client e.g. syntax-case-postlude.scm. I'm sure there are other hook points that would need to be accessible within _gsclib.scm (and possibly other files) too. Perhaps the best way forward is to identify these hooks, maintain existing gambit semantics, and ship a syntax-case-postlude that exercises the new hook functionality.


(Again feel free to clarify what visit/revisit are about. The Scheme community would benefit a lot of a document that describes how the 3-4 main macro systems are used and exactly how they're expanded sufficient for the reader to implement an expander himself, so anyone starting at elementary school would get it.)