Unsafe psyntax label generation

[Mark H Weaver]

Hi Andy,

I'm worried about this change you recently committed:

> diff --git a/module/ice-9/psyntax.scm b/module/ice-9/psyntax.scm
> index 1bf3c32..fd33e98 100644
> --- a/module/ice-9/psyntax.scm
> +++ b/module/ice-9/psyntax.scm
> @@ -636,7 +636,12 @@
>      ;; labels must be comparable with "eq?", have read-write invariance,
>      ;; and distinct from symbols.
>      (define gen-label
> -      (lambda () (symbol->string (gensym "i"))))
> +      (let ((i 0))
> +        (lambda ()
> +          (let ((n i))
> +            ;; FIXME: Use atomic ops.
> +            (set! i (1+ n))
> +            (number->string n 36)))))
>  
>      (define gen-labels
>        (lambda (ls)

I guess you did this as an optimization, but as your comment above
confesses, this optimization is not quite correct.  Apart from the
obvious lack of mutex on the global counter, there's another problem
having to do with your implementation of `local-eval'.

If we use your implementation of `local-eval', I think we may need
universally-unique labels here.

You decided that we didn't, because labels are always compared using
`eq?' and labels from an earlier session will never be `eq?' to labels
generated in a newer session, even if they have the same name.  So far
so good, but there's a case you didn't consider:

`local-eval' combines syntax objects from two different sessions into a
single syntax object (in the wrapper procedure), and thus there may be
label name collisions.  Now, if this combined syntax object is
serialized as a compiled procedure, these labels with the same name will
be optimized together into the same string object!

I think this can actually happen, as follows:

* Session "A" compiles procedure (foo), which uses (the-environment), to
  a .go file.

* Session "B" loads the .go file and calls (foo) to create a
  <lexical-environment>.  Then it uses `local-compile' to compile a
  local-expression that uses (the-environment) again.

Maybe there's something I'm missing here, but if the change you made
above was safe, I think the burden of proof is on you to explain why.

   Thanks,
     Mark