I just happened to run into that exact problem yesterday, and my solution was to have an `id-append` function that returned two values: https://github.com/AlexKnauth/lens/blob/0b026923508eabdff241cad861c5e1c4008cfb19/unstable/lens/private/id-append.rkt <https://github.com/AlexKnauth/lens/blob/0b026923508eabdff241cad861c5e1c4008cfb19/unstable/lens/private/id-append.rkt>
The first for the identifier, and the second for the value of the syntax property, which the user of the function would have to get with define-values and attach it someplace other that the identifier itself. With your fix, (if I only cared about future versions of racket) would it be able to return the identifier with the syntax property on it instead of doing this two-value stuff? Alex Knauth > On Dec 4, 2015, at 11:15 AM, Robby Findler <ro...@eecs.northwestern.edu> > wrote: > > I've pushed a fix to DrRacket to look for the property on occurrences > of binding identifiers. > > Thanks! > > Robby > > On Fri, Dec 4, 2015 at 7:45 AM, Tim Brown <tim.br...@cityc.co.uk> wrote: >> Robby, >> >> Thanks for that. >> >> The following works splendidly for me (and is ripped pretty well >> straight off from the Check_Syntax page you quoted below): >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> (define-syntax (def-a/boxed-a stx) >> (syntax-case stx () >> [(_ base-name base-val) >> (let () >> (define boxed-name >> (format-id #'base-name #:source #'base-name "~a-boxed" >> (syntax-e #'base-name))) >> (define base-len >> (string-length (symbol->string (syntax-e #'base-name)))) >> #`(begin >> (define base-name base-val) >> #,(syntax-property >> #`(define #,boxed-name (box base-val)) >> 'sub-range-binders >> (list >> (vector (syntax-local-introduce boxed-name) >> 0 base-len 0.5 0.5 >> (syntax-local-introduce #'base-name) >> 0 base-len 0.5 0.5)))))])) >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> I can use this, but I can’t add the syntax-property at a place that >> would make it useful in format-id. If I understand correctly) the >> syntax-property is being added to the whole binding of boxed-name to >> (box base-val). If I try to add a property to boxed-name alone: >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> (define-syntax (def-a/boxed-a:2 stx) >> (syntax-case stx () >> [(_ base-name base-val) >> (let () >> (define base-len (string-length (symbol->string (syntax-e >> #'base-name)))) >> (define boxed-name >> (format-id #'base-name #:source #'base-name "~a-boxed" >> (syntax-e #'base-name))) >> >> #`(begin >> (define base-name base-val) >> (define #,(syntax-property >> boxed-name >> 'sub-range-binders >> (list >> (vector (syntax-local-introduce boxed-name) >> 0 base-len 0.5 0.5 >> (syntax-local-introduce #'base-name) >> 0 base-len 0.5 0.5))) >> (box base-val))))])) >> >> (def-a/boxed-a:2 bar 22) >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> The sub-range-bindings on bar-boxed are not recognised (although >> bar-boxed *is* bound to (box 22)). >> >> If I can’t do what I’m trying in def-a/boxed-a:2; I cannot then move the >> wrapping up around format-id to attempt to bake it into format id (by >> mapping it over the ‘v’ arguments, for example). >> >> Is it right to be moving this annotation up into format-id in the first >> place? (I have no opinion now I have a pattern to follow, above). >> >> Suggestions on next steps? >> >> >> Tim >> >> On 04/12/15 13:06, Robby Findler wrote: >>> Looking at the implementation of format-id, I see that it doesn't do >>> what would be needed to be done in order to make the arrows in >>> DrRacket show up like they do for define-syntax. I think this would be >>> a great addition, however! It basically needs to set up some >>> properties on the identifier. >>> >>> If you (or anyone) wants to look into fixing this, these are the relevant >>> docs: >>> >>> http://docs.racket-lang.org/tools/Check_Syntax.html >>> >>> Look for the description of "sub-range-binders". >>> >>> Robby >>> >>> >>> On Fri, Dec 4, 2015 at 4:27 AM, Tim Brown <tim.br...@cityc.co.uk> wrote: >>>> Folks, >>>> >>>> The following program behaves as I would expect: >>>> >>>> ;; ------------------------------------------------------------------ >>>> #lang racket >>>> (require (for-syntax racket/syntax)) >>>> >>>> (define-syntax (def-a/boxed-a stx) >>>> (syntax-case stx () >>>> [(_ base-name base-val) >>>> (with-syntax >>>> ([box-name (format-id #'base-name #:source #'base-name >>>> "~a-boxed" (syntax-e #'base-name))]) >>>> #'(begin >>>> (define base-name base-val) >>>> (define box-name (box base-val))))])) >>>> >>>> >>>> (def-a/boxed-a tim #;[1] "42") >>>> >>>> tim #;[2] >>>> >>>> tim-boxed #;[3] >>>> ;; ------------------------------------------------------------------ >>>> >>>> Prints: >>>> "22" >>>> '#&"22" >>>> >>>> So the variables are defined (maybe that’s a bit of a naïve description >>>> of what’s happened). >>>> >>>> But... in DrRacket, I get a blue binding line from the tim at [2] to >>>> the tim at [1]; however, I don’t get a line from tim-boxed at [3] to >>>> the tim at [2]. >>>> >>>> Am I missing something? >>>> I thought I had annotated the format-id with the necessary. >>>> >>>> How does Racket know that tim is defined at [1], but not know that >>>> tim-boxed is also defined (for my purposes) at [1]? >>>> >>>> And, strictly, what do the blue lines indicate? >>>> >>>> >>>> Some context: >>>> I am actually using `prepare` to prepare some database queries. So I >>>> have macros to define: find-a-thing-sql and find-a-thing-sql/prepared >>>> For the most part I use find-a-thing-sql/prepared in my queries; so >>>> *that* is what I want to jump back to the definition of using >>>> "Jump to Binding Occurrence". >>>> >>>> Thanks in advance, >>>> >>>> Tim >>>> >>>> -- >>>> Tim Brown CEng MBCS <tim.br...@cityc.co.uk> >>>> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ >>>> City Computing Limited · www.cityc.co.uk >>>> City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB >>>> T:+44 20 8770 2110 · F:+44 20 8770 2130 >>>> ──────────────────────────────────────────────────────────────────────── >>>> City Computing Limited registered in London No:1767817. >>>> Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE >>>> VAT No: GB 918 4680 96 >>>> >>>> -- >>>> >>> >> >> >> -- >> Tim Brown CEng MBCS <tim.br...@cityc.co.uk> >> ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ >> City Computing Limited · www.cityc.co.uk >> City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB >> T:+44 20 8770 2110 · F:+44 20 8770 2130 >> ──────────────────────────────────────────────────────────────────────── >> City Computing Limited registered in London No:1767817. >> Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE >> VAT No: GB 918 4680 96 > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
