[racket] Lazy syntax class attributes

Confirmed that it is internal to syntax parse.

#lang racket

(begin-for-syntax
  (require syntax/parse racket/promise)
  (define-syntax-class foo
    (pattern x:id
      #:attr y (delay (displayln (syntax->datum #'x)) #''x))))


(define-syntax bar
  (syntax-parser
    ((_ a:foo b:foo c:foo d:foo e:foo f:foo g:foo)
     #'(list a.y b.y c.y d.y e.y f.y g.y))))

(bar a b c d e f g)

This program sometimes changes the output (racket vs. raco make,
seemed the best way to trigger it)

endobson at yggdrasil () ~/proj/racket/plt % racket ~/tmp/tmp.rkt (0)
d
b
c
e
f
g
a
'(a b c d e f g)
endobson at yggdrasil () ~/proj/racket/plt % raco make ~/tmp/tmp.rkt (0)
c
d
e
f
g
a
b

What does the syntax-parse API guarantee about this?

On Sun, Jun 9, 2013 at 10:55 AM, Eric Dobson <eric.n.dobson at gmail.com> wrote:
> I'm seeing something which looks like on different runs of my program
> different attributes are forced in different orders. The change that
> triggers this is changing something unrelated in the syntax pattern.
> I'm still working at understanding what is triggering this so that I
> can reproduce a small test case.
>
> The basic code is that #'(op.unsafe e1.opt e2.opt) seems to force
> e1.opt first sometimes and sometimes e2.opt is forced first. Could
> this be a hash iteration order issue in the internals of syntax/parse?
>
> On Wed, Jun 5, 2013 at 4:58 PM, Eric Dobson <eric.n.dobson at gmail.com> wrote:
>> I started working with this last night, and it simplified the code a
>> lot. I was able to build syntax classes on top of other ones with a
>> lot less worrying about when the slow path would be run. (And
>> uncovered a couple of optimizer bugs in the process).
>>
>>
>> On Wed, Jun 5, 2013 at 2:05 PM, Ryan Culpepper <ryanc at ccs.neu.edu> wrote:
>>> I've implemented what I described earlier, as well as the error on 3D values
>>> in a #:with clause or ~parse right-hand side.
>>>
>>> Pattern variables that come from syntax-parse already acted differently; if
>>> they weren't syntax-valued, they raised errors. All I've done now is turn
>>> some error cases into non-error cases.
>>>
>>> Ryan
>>>
>>>
>>>
>>> On 06/01/2013 11:55 AM, Eric Dobson wrote:
>>>>
>>>> I would say not to implement this just on my behalf. I think it would
>>>> be weird for pattern variables to act differently if they came from
>>>> syntax-parse versus from with-syntax.
>>>>
>>>> On Fri, May 31, 2013 at 2:17 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
>>>> wrote:
>>>>>
>>>>> On Fri, May 31, 2013 at 4:42 PM, Ryan Culpepper <ryanc at ccs.neu.edu>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Note, however, that the syntax class now uses #:attr instead of #:with.
>>>>>> That's the main usability issue I'm worried about with this change.
>>>>>> Following with-syntax's lead, a #:with clause automatically converts its
>>>>>> right-hand side to syntax---even if the result is "3D". That means that
>>>>>> if
>>>>>> you forget that step of the conversion to laziness, you'll probably get
>>>>>> bizarre 3D syntax. I could change #:with to raise an error in some/all
>>>>>> 3D
>>>>>> cases, but that might break existing programs.
>>>>>>
>>>>>> Is anyone out there using syntax-parse to make 3D syntax?
>>>>>
>>>>>
>>>>> I'm sure all the places where I do this are bugs (and it has happened
>>>>> to me), so I'd welcome this error.
>>>>>
>>>>> Sam
>>>
>>>