Gambit people,
After formerly providing a patch that provides rudimentary support for compiled syntax-case modules with Gambit scheme, I'd like to share some recent thoughts that have emerged since I first posted.
It was not long after the patch was included in the head, when user Sven Hartrumpf reported that the change regressed compiler functionality on 9/21. Since that time, I have been examining ways to make compilation seamless, which I think means:
1. Compilation should regress, wherein one may use gsc -:s -o <output> -exe <file1> <file2> ... without seeing additional warnings, and correctly run the resultant output. This is true for all other forms of compilation, which include both incremental and flat linking. Anything that is 'standards compliant' should compile correctly with just -:s specified, and ultimately link correctly when presented with other -:s generated output. The syntax-case file should never need to be loaded or included for standards compliant mode, other than internally by Gambit via -:s.
2. Executables and their dependent libraries should not depend on $sc-put-cte, or inclusion/loading of any syntax-case code. syntax-case is an expander and is not needed as a dependency.
3. Flat link files that are loaded into the REPL need $sc-put-cte content present, to effect functionality that was enabled by the former patch. The syntactic environment needs extension as objects are loaded.
In the meantime, I went looking in the Chez manual to better identify how it uses syntax-case. I found the definitions for the visit and revisit primitives useful. Dybvig states:
"visit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that establish compile-time information or correspond to expressions identified as "visit" time by eval-when forms contained in the original source file."
"revisit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that compute run-time values or correspond to expressions identified as "revisit" time by eval-when forms contained in the original source file."
(from http://www.scheme.com/csug8/system.html)
Thus, from a Gambit schemer's perspective: The visit function is that which can "generate" what we conventionally place in a compilable <file>#.scm file from a source of mixed syntax definitions and program. The revisit function provides the program content, with syntax definitions and module metadata stripped.
When one examines psyntax73.ss, there are two comments provided on the definitions of build-visit-only and build-revisit-only, the two syntaxes that result in the creation of the respective residuals for visit and revisit:
(define-syntax build-visit-only ; should mark the result as "visit only" for compile-file ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp)))
(define-syntax build-revisit-only ; should mark the result as "revisit only" for compile-file, ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp)))
Although it is clear to me that Gambit needs credible implementations for these, my most sophisticated patch to date involves writing two files at compile time, one that contains visit content, and another (the main expander output) that contains the revisit content. I believe that it is necessary to generate both of these files in a single pass, and the generate-id implementation ensures they are uniquely paired.
I foresee the following immediate consequences of this implementation:
1. The generation of files, especially the scheme visit content, that were formerly not compiler outputs is undesirable behavior.
2. The c#expand-source is not capable of compiling a second scheme file as a side-effect of compilation. (... or is re-entrant in the general case?!) To proceed, one would have to wrap the compiler with a pre-processor to expand the visit content and perform separate compilations of both visit and revisit content.
3. In a current patch I'm working on without #2, to support symmetric syntax use between to compile units, one must duplicate source files in a compiler command line, just as needs to feed a worse-is-better UNIX ld implementation e.g.
gsc -:s -c a b a
The first listing of a generates the visit information for compile unit b, whereas the second listing of a provides a correct revisit of a with the visited definitions of b present.
I suspect that it is thus necessary for a reasonable implementation of visit to transitively visit all dependencies until a graph of visits is closed, prior to compiling a revisit for a compilation unit.
As an aside, all this dogma makes me very happy of the basic choice of Gambit's define-macro, namespaces, and <file>#.scm design. It certainly makes for a beautifully simple scheme implementation, and cuts a lot of needless complexity. Perhaps the original bundling of syntax-case by Marc was an excellent local optima, use of ##include to propagate standards compliant syntax, and use of continued ##namespace for module support.
Moving forwards, with the inadequacies of the dual file implementation, I'd like to consider the possibility of building both visit and revisit information into a single object file. To effect this, I've studied the structure of the generated C, which has ripped by brain apart, and I've also looked at other possible mechanisms, like, for example injecting visit information into the linker info structure. I believe the practice of coupling visit + revisit content in a single object will simplify the compiled syntax-case experience for users, and also provide gsc contract continuance as described above, so that existing gambit codebases don't regress. In terms of Dybvig's comments above: How does the community best think "marking of visit/revisit" should occur so that full syntax-case integration can be achieved, assuming this is indeed a desirable goal!
Kind regards, Matt Hastie.
Afficher les réponses par date
Dont put *too* much effort into it.
Of course thats not to say that this is not useful or the Right Thing™, it is.
We definitely need the ability to boot through chez-like macro systems, and -:s sounds like a great idea for having a standard (common) scheme mode.
My recommendation would be to make sure it works with (incremental) dynamically linked modules. Supporting teh flat(t ;) link files is like shooting at a moving target and then there is name mangling.
-- vyzo™
PS: Are you adding it to the missie as well?
My greets to eli, sam, and (of course) Matthias. On Oct 21, 2013 10:47 PM, "Matt Hastie" matthastie@gmail.com wrote:
Gambit people,
After formerly providing a patch that provides rudimentary support for compiled syntax-case modules with Gambit scheme, I'd like to share some recent thoughts that have emerged since I first posted.
It was not long after the patch was included in the head, when user Sven Hartrumpf reported that the change regressed compiler functionality on 9/21. Since that time, I have been examining ways to make compilation seamless, which I think means:
- Compilation should regress, wherein one may use gsc -:s -o <output>
-exe <file1> <file2> ... without seeing additional warnings, and correctly run the resultant output. This is true for all other forms of compilation, which include both incremental and flat linking. Anything that is 'standards compliant' should compile correctly with just -:s specified, and ultimately link correctly when presented with other -:s generated output. The syntax-case file should never need to be loaded or included for standards compliant mode, other than internally by Gambit via -:s.
- Executables and their dependent libraries should not depend on
$sc-put-cte, or inclusion/loading of any syntax-case code. syntax-case is an expander and is not needed as a dependency.
- Flat link files that are loaded into the REPL need $sc-put-cte content
present, to effect functionality that was enabled by the former patch. The syntactic environment needs extension as objects are loaded.
In the meantime, I went looking in the Chez manual to better identify how it uses syntax-case. I found the definitions for the visit and revisit primitives useful. Dybvig states:
"visit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that establish compile-time information or correspond to expressions identified as "visit" time by eval-when forms contained in the original source file."
"revisit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that compute run-time values or correspond to expressions identified as "revisit" time by eval-when forms contained in the original source file."
(from http://www.scheme.com/csug8/system.html)
Thus, from a Gambit schemer's perspective: The visit function is that which can "generate" what we conventionally place in a compilable <file>#.scm file from a source of mixed syntax definitions and program. The revisit function provides the program content, with syntax definitions and module metadata stripped.
When one examines psyntax73.ss, there are two comments provided on the definitions of build-visit-only and build-revisit-only, the two syntaxes that result in the creation of the respective residuals for visit and revisit:
(define-syntax build-visit-only ; should mark the result as "visit only" for compile-file ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp)))
(define-syntax build-revisit-only ; should mark the result as "revisit only" for compile-file, ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp)))
Although it is clear to me that Gambit needs credible implementations for these, my most sophisticated patch to date involves writing two files at compile time, one that contains visit content, and another (the main expander output) that contains the revisit content. I believe that it is necessary to generate both of these files in a single pass, and the generate-id implementation ensures they are uniquely paired.
I foresee the following immediate consequences of this implementation:
- The generation of files, especially the scheme visit content, that were
formerly not compiler outputs is undesirable behavior.
- The c#expand-source is not capable of compiling a second scheme file as
a side-effect of compilation. (... or is re-entrant in the general case?!) To proceed, one would have to wrap the compiler with a pre-processor to expand the visit content and perform separate compilations of both visit and revisit content.
- In a current patch I'm working on without #2, to support symmetric
syntax use between to compile units, one must duplicate source files in a compiler command line, just as needs to feed a worse-is-better UNIX ld implementation e.g.
gsc -:s -c a b a
The first listing of a generates the visit information for compile unit b, whereas the second listing of a provides a correct revisit of a with the visited definitions of b present.
I suspect that it is thus necessary for a reasonable implementation of visit to transitively visit all dependencies until a graph of visits is closed, prior to compiling a revisit for a compilation unit.
As an aside, all this dogma makes me very happy of the basic choice of Gambit's define-macro, namespaces, and <file>#.scm design. It certainly makes for a beautifully simple scheme implementation, and cuts a lot of needless complexity. Perhaps the original bundling of syntax-case by Marc was an excellent local optima, use of ##include to propagate standards compliant syntax, and use of continued ##namespace for module support.
Moving forwards, with the inadequacies of the dual file implementation, I'd like to consider the possibility of building both visit and revisit information into a single object file. To effect this, I've studied the structure of the generated C, which has ripped by brain apart, and I've also looked at other possible mechanisms, like, for example injecting visit information into the linker info structure. I believe the practice of coupling visit + revisit content in a single object will simplify the compiled syntax-case experience for users, and also provide gsc contract continuance as described above, so that existing gambit codebases don't regress. In terms of Dybvig's comments above: How does the community best think "marking of visit/revisit" should occur so that full syntax-case integration can be achieved, assuming this is indeed a desirable goal!
Kind regards, Matt Hastie.
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
A correction:
- Compilation should *not* regress, wherein one may use gsc -:s -o <output> -exe <file1> <file2> ... without seeing additional warnings, and correctly run the resultant output. This is true for all other forms of compilation, which include both incremental and flat linking. Anything that is 'standards compliant' should compile correctly with just -:s specified, and ultimately link correctly when presented with other -:s generated output. The syntax-case file should never need to be loaded or included for standards compliant mode, other than internally by Gambit via -:s.
Derrrrp.
On Oct 21, 2013, at 10:46 PM, Matt Hastie matthastie@gmail.com wrote:
Gambit people,
After formerly providing a patch that provides rudimentary support for compiled syntax-case modules with Gambit scheme, I'd like to share some recent thoughts that have emerged since I first posted.
It was not long after the patch was included in the head, when user Sven Hartrumpf reported that the change regressed compiler functionality on 9/21. Since that time, I have been examining ways to make compilation seamless, which I think means:
Compilation should regress, wherein one may use gsc -:s -o <output> -exe <file1> <file2> ... without seeing additional warnings, and correctly run the resultant output. This is true for all other forms of compilation, which include both incremental and flat linking. Anything that is 'standards compliant' should compile correctly with just -:s specified, and ultimately link correctly when presented with other -:s generated output. The syntax-case file should never need to be loaded or included for standards compliant mode, other than internally by Gambit via -:s.
Executables and their dependent libraries should not depend on $sc-put-cte, or inclusion/loading of any syntax-case code. syntax-case is an expander and is not needed as a dependency.
Flat link files that are loaded into the REPL need $sc-put-cte content present, to effect functionality that was enabled by the former patch. The syntactic environment needs extension as objects are loaded.
In the meantime, I went looking in the Chez manual to better identify how it uses syntax-case. I found the definitions for the visit and revisit primitives useful. Dybvig states:
"visit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that establish compile-time information or correspond to expressions identified as "visit" time by eval-when forms contained in the original source file."
"revisit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that compute run-time values or correspond to expressions identified as "revisit" time by eval-when forms contained in the original source file."
(from http://www.scheme.com/csug8/system.html)
Thus, from a Gambit schemer's perspective: The visit function is that which can "generate" what we conventionally place in a compilable <file>#.scm file from a source of mixed syntax definitions and program. The revisit function provides the program content, with syntax definitions and module metadata stripped.
When one examines psyntax73.ss, there are two comments provided on the definitions of build-visit-only and build-revisit-only, the two syntaxes that result in the creation of the respective residuals for visit and revisit:
(define-syntax build-visit-only ; should mark the result as "visit only" for compile-file ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp)))
(define-syntax build-revisit-only ; should mark the result as "revisit only" for compile-file, ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp)))
Although it is clear to me that Gambit needs credible implementations for these, my most sophisticated patch to date involves writing two files at compile time, one that contains visit content, and another (the main expander output) that contains the revisit content. I believe that it is necessary to generate both of these files in a single pass, and the generate-id implementation ensures they are uniquely paired.
I foresee the following immediate consequences of this implementation:
The generation of files, especially the scheme visit content, that were formerly not compiler outputs is undesirable behavior.
The c#expand-source is not capable of compiling a second scheme file as a side-effect of compilation. (... or is re-entrant in the general case?!) To proceed, one would have to wrap the compiler with a pre-processor to expand the visit content and perform separate compilations of both visit and revisit content.
In a current patch I'm working on without #2, to support symmetric syntax use between to compile units, one must duplicate source files in a compiler command line, just as needs to feed a worse-is-better UNIX ld implementation e.g.
gsc -:s -c a b a
The first listing of a generates the visit information for compile unit b, whereas the second listing of a provides a correct revisit of a with the visited definitions of b present.
I suspect that it is thus necessary for a reasonable implementation of visit to transitively visit all dependencies until a graph of visits is closed, prior to compiling a revisit for a compilation unit.
As an aside, all this dogma makes me very happy of the basic choice of Gambit's define-macro, namespaces, and <file>#.scm design. It certainly makes for a beautifully simple scheme implementation, and cuts a lot of needless complexity. Perhaps the original bundling of syntax-case by Marc was an excellent local optima, use of ##include to propagate standards compliant syntax, and use of continued ##namespace for module support.
Moving forwards, with the inadequacies of the dual file implementation, I'd like to consider the possibility of building both visit and revisit information into a single object file. To effect this, I've studied the structure of the generated C, which has ripped by brain apart, and I've also looked at other possible mechanisms, like, for example injecting visit information into the linker info structure. I believe the practice of coupling visit + revisit content in a single object will simplify the compiled syntax-case experience for users, and also provide gsc contract continuance as described above, so that existing gambit codebases don't regress. In terms of Dybvig's comments above: How does the community best think "marking of visit/revisit" should occur so that full syntax-case integration can be achieved, assuming this is indeed a desirable goal!
Kind regards, Matt Hastie.
Matt, thank you for your detailed analysis. My comments follow.
On 2013-10-22, at 1:46 AM, Matt Hastie matthastie@gmail.com wrote:
Gambit people,
After formerly providing a patch that provides rudimentary support for compiled syntax-case modules with Gambit scheme, I'd like to share some recent thoughts that have emerged since I first posted.
It was not long after the patch was included in the head, when user Sven Hartrumpf reported that the change regressed compiler functionality on 9/21. Since that time, I have been examining ways to make compilation seamless, which I think means:
- Compilation should regress, wherein one may use gsc -:s -o <output> -exe <file1> <file2> ... without seeing additional warnings, and correctly run the resultant output. This is true for all other forms of compilation, which include both incremental and flat linking. Anything that is 'standards compliant' should compile correctly with just -:s specified, and ultimately link correctly when presented with other -:s generated output. The syntax-case file should never need to be loaded or included for standards compliant mode, other than internally by Gambit via -:s.
I agree that compilation should not regress.
- Executables and their dependent libraries should not depend on $sc-put-cte, or inclusion/loading of any syntax-case code. syntax-case is an expander and is not needed as a dependency.
I agree.
- Flat link files that are loaded into the REPL need $sc-put-cte content present, to effect functionality that was enabled by the former patch. The syntactic environment needs extension as objects are loaded.
Having access to compiled macros in the REPL would be nice indeed.
In the meantime, I went looking in the Chez manual to better identify how it uses syntax-case. I found the definitions for the visit and revisit primitives useful. Dybvig states:
"visit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that establish compile-time information or correspond to expressions identified as "visit" time by eval-when forms contained in the original source file."
"revisit reads the named file, which must contain compiled object code compatible with the current machine type and version, and it runs those portions of the compiled object code that compute run-time values or correspond to expressions identified as "revisit" time by eval-when forms contained in the original source file."
(from http://www.scheme.com/csug8/system.html)
Thus, from a Gambit schemer's perspective: The visit function is that which can "generate" what we conventionally place in a compilable <file>#.scm file from a source of mixed syntax definitions and program. The revisit function provides the program content, with syntax definitions and module metadata stripped.
When one examines psyntax73.ss, there are two comments provided on the definitions of build-visit-only and build-revisit-only, the two syntaxes that result in the creation of the respective residuals for visit and revisit:
(define-syntax build-visit-only ; should mark the result as "visit only" for compile-file ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp)))
(define-syntax build-revisit-only ; should mark the result as "revisit only" for compile-file, ; in implementations that support visit/revisit (syntax-rules () ((_ exp) exp)))
Although it is clear to me that Gambit needs credible implementations for these, my most sophisticated patch to date involves writing two files at compile time, one that contains visit content, and another (the main expander output) that contains the revisit content. I believe that it is necessary to generate both of these files in a single pass, and the generate-id implementation ensures they are uniquely paired.
I foresee the following immediate consequences of this implementation:
The generation of files, especially the scheme visit content, that were formerly not compiler outputs is undesirable behavior.
The c#expand-source is not capable of compiling a second scheme file as a side-effect of compilation. (... or is re-entrant in the general case?!) To proceed, one would have to wrap the compiler with a pre-processor to expand the visit content and perform separate compilations of both visit and revisit content.
In a current patch I'm working on without #2, to support symmetric syntax use between to compile units, one must duplicate source files in a compiler command line, just as needs to feed a worse-is-better UNIX ld implementation e.g.
gsc -:s -c a b a
The first listing of a generates the visit information for compile unit b, whereas the second listing of a provides a correct revisit of a with the visited definitions of b present.
I suspect that it is thus necessary for a reasonable implementation of visit to transitively visit all dependencies until a graph of visits is closed, prior to compiling a revisit for a compilation unit.
As an aside, all this dogma makes me very happy of the basic choice of Gambit's define-macro, namespaces, and <file>#.scm design. It certainly makes for a beautifully simple scheme implementation, and cuts a lot of needless complexity. Perhaps the original bundling of syntax-case by Marc was an excellent local optima, use of ##include to propagate standards compliant syntax, and use of continued ##namespace for module support.
Moving forwards, with the inadequacies of the dual file implementation, I'd like to consider the possibility of building both visit and revisit information into a single object file. To effect this, I've studied the structure of the generated C, which has ripped by brain apart, and I've also looked at other possible mechanisms, like, for example injecting visit information into the linker info structure. I believe the practice of coupling visit + revisit content in a single object will simplify the compiled syntax-case experience for users, and also provide gsc contract continuance as described above, so that existing gambit codebases don't regress. In terms of Dybvig's comments above: How does the community best think "marking of visit/revisit" should occur so that full syntax-case integration can be achieved, assuming this is indeed a desirable goal!
Kind regards, Matt Hastie.
The main problem I see is one of *packaging*. 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. 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.
Comments welcome...
Marc
On Oct 22, 2013, at 8:43 AM, Marc Feeley feeley@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.
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@gmail.com
On Oct 22, 2013, at 8:43 AM, Marc Feeley feeley@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@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
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. 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.
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... . (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.)
-
Dimitris Vyzovitis -
Marc Feeley -
Matt Hastie -
Mikael