Andy Wingo <wi...@pobox.com> writes:
> I've rebased the syncase branch on top of current master, and fixed
> everything I know about. Now you can have macros in modules that expand
> to references to identifiers that are local to the module that the macro
> was defined in.
"serialize module information into syncase's output -- getting ready
for hygiene"
Renaming (ice-9 annotate) to (ice-9 expand-support)... is that really
compelling enough for the risk of upsetting someone (if there is
anyone!) who is using (ice-9 annotate) ?
So far, not understanding why we don't generate (@ ...) or (@@
... directly), but perhaps that will become clear.
"add modules to syntax objects (part 1, intermediate step)"
Out of interest, why use a vector here, whereas in the previous commit
you used structs?
"finish bootstrap to syntax-objects with modules"
OK. I see now why the vector representation didn't matter. I hadn't
realized before that psyntax.scm required itself to bootstrap.
"thread the module through syntax-case's expansion"
+SCM_DEFINE (scm_procedure_module, "procedure-module", 1, 0, 0,
+ (SCM proc),
+ "Return the module that was current when this procedure was defined.\n"
+ "Free variables in this procedure are resolved relative to the\n"
+ "procedure's module.")
Can you delete the second sentence? I think the concept of how
variables are resolved belongs elsewhere, and mentioning it here feels
slightly worrying - suggesting (to me, very slightly, and no matter
how strange that would be) that proper resolution might only happen
for procedures for which procedure-module is called.
+#define FUNC_NAME s_scm_procedure_module
+{
+ SCM_VALIDATE_PROC (SCM_ARG1, proc);
Could you use scm_env_module () here to simplify the code?
"eval-closure-module, here hopefully not for long"
OK.
"more work on modules and hygiene, not finished yet, alas."
Hmm, "eval closures are so 1990s": I think I agree, but I believe the
idea of eval closures was to allow other top levels than modules (and
the root). In case anyone out there is actually using a non-module
eval closure, are we inadvertently removing support for using syncase
with such top levels?
+ ;(debug-disable 'debug 'procnames)
+ ;(read-disable 'positions)
Is that temporary?
-;; The following lines are necessary only if we start making changes
-;; (use-syntax sc-expand)
-;; (load-from-path "ice-9/psyntax")
Am I correct in thinking that we have Makefile rules to automatically
do the needed generation when psyntax.scm changes?
"houston, we have hygiene"
Hooray!
- (build-global-reference (source-annotation (car e)) value mod)
+ (build-global-reference (source-annotation (car e)) value
+ (if (syntax-object? (car e))
+ (syntax-object-module (car e))
+ mod))
Didn't understand this change, and I'm not sure if the changelog
covers it. Can you explain more?
"hygienic compilation"
OK. Am I correct in thinking that this is just an optimization -
i.e. that the VM would correctly interpret the @ and @@ macros later
on if they weren't intercepted here?
"@ and @@ as primitive macros"
+ ASSERT_SYNTAX (scm_ilength (expr) == 3, s_bad_expression, expr);
+ ASSERT_SYNTAX (scm_ilength (scm_cadr (expr)) > 0, s_bad_expression, expr);
I think it would be helpful to also assert that the caddr is a
symbol. (Also in @@)
"fix handling of pre-modules errors in the vm"
OK.
"fix hygiene + modules + local macros"
- #:export (pmatch ppat))
+ #:export (pmatch))
;; FIXME: shouldn't have to export ppat...
Can remove the FIXME too now!
Overall...
Great stuff!
I believe this implementation confirms the point that we're relying on
(define-module ...) to have a lexical effect, and hence (given that
define-module isn't actually syntax) on the fact that Guile reads and
evaluates top-level forms from a file or the REPL sequentially. I
think we should just make that explicit somewhere, for anyone looking
in future at a different way of reading files. How does the compiler
handle this, does it look specifically for define-module forms when
reading?
Regards,
Neil
