[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unsafe psyntax label generation
From: |
Mark H Weaver |
Subject: |
Re: Unsafe psyntax label generation |
Date: |
Tue, 24 Jan 2012 20:41:44 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Andy Wingo <address@hidden> writes:
> On Tue 24 Jan 2012 15:01, Mark H Weaver <address@hidden> writes:
>
>> `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!
>
> A very good point!
>
> Cf. Aziz's psyntax/expander.ss from r6rs-libraries.dev:
>
> ;;; (two marks must be eq?-comparable, so we use a string
> ;;; of one char (this assumes that strings are mutable)).
>
> ;;; gen-mark generates a new unique mark
> (define (gen-mark) ;;; faster
> (string #\m))
>
> ;;; every identifier in the program would have a label associated
> ;;; with it in its substitution. gen-label generates such labels.
> ;;; the labels have to have read/write eq? invariance to support
> ;;; separate compilation.
> (define gen-label
> (lambda (_) (gensym)))
>
> His gensyms are globally unique; he made the exact opposite choice that
> I did in the fd5985271fee3bcb6a290b6ad10525980a97ef8d; interesting. I
> wonder who is right here.
John Cowan's recent message on scheme-reports "Re: fresh empty strings"
suggests that Ikarus does not merge equal string literals into a single
object, so I guess in that case his `gen-mark' would work properly.
>> 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.
>
> Indeed, and I think you found a good indication that it's not right.
How would you like to fix this? Would you like me to make a new
procedure that creates a universally-unique string? Most of `gensym's
current code would be moved to that new procedure, and then `gensym'
would use it.
Thanks,
Mark