Re: request review & testing: syncase

[Neil Jerram]

Andy Wingo <address@hidden> 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