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
#
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
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
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 Culpepp
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
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 wrote:
> On Fri, May 31, 2013 at 4:42 PM, Ryan Culpepper wrote:
>>
On Fri, May 31, 2013 at 4:42 PM, Ryan Culpepper 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 s
On 05/31/2013 02:47 AM, Eric Dobson wrote:
I'm working on code (TR optimizer) that needs to match some
expressions and then compute an attribute based on the expression. I
would like to abstract this out as a syntax class. Example is below:
#lang racket
(require syntax/parse)
(define-syntax-cla
You would have to implement laziness for attributes manually -- I think.
But I don't have time to play with code and get an example to work right
now. -- Matthias
On May 31, 2013, at 11:00 AM, Eric Dobson wrote:
> That seems like a a workable amount of overhead, but I'm not sure what
> you ar
-lang.org
> Sent: Friday, May 31, 2013 11:00:13 AM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket] Lazy syntax class attributes
>
> That seems like a a workable amount of overhead, but I'm not sure what
> you are suggesting the v attribute to be bound as. It might have
rhs ...
Too much?
-Ian
- Original Message -
From: "Eric Dobson"
To: "Matthias Felleisen"
Cc: users@racket-lang.org
Sent: Friday, May 31, 2013 11:00:13 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket] Lazy syntax class attributes
That seems like a a workable amou
That seems like a a workable amount of overhead, but I'm not sure what
you are suggesting the v attribute to be bound as. It might have not
been obvious from my my example that its value depends on the slow
computation, so unless pattern variables can be mutated I'm not sure
how force-all can chang
Can you prefix the #'(complicated ..) expression with a form
that forces all lazy computations so that complicated itself
remains the same?
(let () (force-all) #'(complicated (form e.v)))
where force-all is defined via a begin in the slow syntax class?
-- Matthias
On May 31, 2013, at 2:4
I'm working on code (TR optimizer) that needs to match some
expressions and then compute an attribute based on the expression. I
would like to abstract this out as a syntax class. Example is below:
#lang racket
(require syntax/parse)
(define-syntax-class slow
(pattern e:expr
#:with v
14 matches
Mail list logo
