[racket] Lazy syntax class attributes

I think it's actually due to the implementation of the 'syntax' form: it 
collects pattern variables in a hash table.

I don't think you should expect promises to be forced in a particular 
order. If you absolutely need them to, you should probably force them 
yourself. For example, instead of

#'(op.unsafe e1.opt e2.opt)

write

(begin
  (void #'e1.opt #'e2.opt)  ;; force in order
  #'(op.unsafe e1.opt e2.opt))

Ryan


On 06/09/2013 03:19 PM, Eric Dobson wrote:
> 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
>>>>
>>>>