[racket-dev] provide expand-clause in racket/private/for.rkt

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Fri Sep 6 16:53:34 EDT 2013

Now that you've pushed this, it occurs to me why it's probably unsafe:
some `in-...' forms expand to unsafe operations, right?

If I'm right about that, then we should probably move the function to
`racket/unsafe/for-transform' and protect the export.

(Or, since I see that you put the library in `syntax/for-transform',
maybe `syntax/unsafe/for-transform'?)

At Fri, 6 Sep 2013 14:44:20 -0400, Stephen Chang wrote:
> On Fri, Sep 6, 2013 at 7:54 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > As far as I can see, exporting `expand-clause` is ok.
> >
> > Ideally, I think it should be exported from a new
> > `racket/for-transform` library, instead of used directly from
> > `racket/private/for`. Also, `expand-for-clause` might be a better name.
> 
> Ok I will add it. Thanks.
> 
> 
> >
> > At Fri, 6 Sep 2013 00:45:40 -0400, Stephen Chang wrote:
> >> Hi dev,
> >>
> >> I would like to provide (for-syntax) the "expand-clause" function in
> >> racket/private/for.rkt. Would this cause any problems? Would anyone
> >> object to this?
> >>
> >> I have an implementation of for/X in my generic-bind library that uses
> >> expand-clause and with it, the generic-bind ~for forms are as fast,
> >> sometimes a little faster, than racket's for/X in some preliminary
> >> testing. (Without access to expand-clause, sequence traversal is slow
> >> --- the current planet-available version of my library uses
> >> sequence-generate and is twice as slow.)
> >>
> >> The "sometimes a little faster" is likely in part due to less
> >> error-checking, but my implementation passes all the for/X unit tests
> >> and so as is, it can reasonably be used in place of for/X.
> >> _________________________
> >>   Racket Developers list:
> >>   http://lists.racket-lang.org/dev
> >

Posted on the dev mailing list.