[racket] Lazy syntax class attributes

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
>
>