On Sep 7, 2011, at 10:40 AM, Carl Eastlund wrote: > On Wed, Sep 7, 2011 at 1:37 PM, John Clements <[email protected]> > wrote: >> >> On Sep 6, 2011, at 8:12 PM, Sam Tobin-Hochstadt wrote: >> >>> On Tue, Sep 6, 2011 at 8:05 PM, John Clements <[email protected]> >>> wrote: >>>> >>>> On Aug 18, 2011, at 5:32 AM, Sam Tobin-Hochstadt wrote: >>>> >>>>> >>>>> Yes, I understand why this happens. As I see it, there are a few >>>>> possibilities: >>>>> >>>>> 1. The expander should check for duplicates, in some fashion. >>>>> 2. This idiom is problematic, in the case where `stx' is both the >>>>> input and used for the syntax properties of the output. >>>>> 3. Macros may freely duplicate syntax properties. >>>>> >>>>> All of these have drawbacks, but (3), which you are suggesting, means >>>>> either that syntax properties can only be used to specify idempotent >>>>> information or that the non-idempotent ones need to have some >>>>> *explicit* means by which equal elements can be distinguished, which >>>>> must be part of the API of that syntax property. >>>>> >>>>> If we think this is how syntax properties ought to work, then we >>>>> should add something to the documentation making this clear, and we >>>>> should recognize that it's a limitation. >>>> >>>> Would syntax-property guards solve this problem? >>> >>> I don't really see how. What are you thinking of? >> >> A guard could keep track of duplicates. Keep in mind that syntax-property >> guards are purely a > figment of my imagination. > > What, in your imagination, is a syntax-property guard?
I imagine that when the key involved in the property is a special guarded-syntax-property value, then an associated procedure gets to decide (approve/reject, substitute an alternate value?) whether a value should be used. If I understand the problem, the obvious danger in an idea such as this is opening a "back door" into expansion time. Apologies if I've misunderstood the issue. John
smime.p7s
Description: S/MIME cryptographic signature
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
