[racket-dev] syntax property duplication

From: Sam Tobin-Hochstadt (samth at ccs.neu.edu)
Date: Thu Aug 18 08:32:03 EDT 2011

On Thu, Aug 18, 2011 at 8:14 AM, Carl Eastlund <cce at ccs.neu.edu> wrote:
> On Wed, Aug 17, 2011 at 6:25 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
>> The following idiom duplicates the syntax properties on `stx':
>>
>>  (define-syntax (m stx) (datum->syntax #'here 'id stx stx))
>>
>> This is a problem for me because I use syntax properties to indicate
>> polymorphic type instantiation.  If an expression that's actually a
>> macro using this idiom is instatiated, then Typed Racket tries to do
>> the type instantiation twice, resulting in an error.  See the below
>> program, which fails.
>>
>> Should I expect that duplicate syntax properties are a natural result
>> of expansion, and find some way to handle them?  Or is there something
>> else that should happen?
>>
>> #lang typed/racket
>> (: id : (All (A) (A -> A)))
>> (define (id x) x)
>> (define-syntax (m stx) (datum->syntax #'here 'id stx stx))
>> (inst m Integer)
>>
> Merging syntax properties -- duplicating in this case, since the
> macro's input and output have the same properties -- are a natural
> result of expansion, as you say.  See the third paragraph in the
> reference on syntax properties:

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.
-- 
sam th
samth at ccs.neu.edu



Posted on the dev mailing list.