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

[Stephen Chang]

On Fri, Sep 6, 2013 at 4:53 PM, Matthew Flatt  wrote:
> Now that you've pushed this, it occurs to me why it's probably unsafe:
> some `in-...' forms expand to unsafe operations, right?

Yes that is true. At least in-vector does and probably others.


> 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'?)

I put it in syntax/ because I saw that's where split-for-body is.




>
> At Fri, 6 Sep 2013 14:44:20 -0400, Stephen Chang wrote:
>> On Fri, Sep 6, 2013 at 7:54 AM, Matthew Flatt  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
>> >
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] split-for-body from syntax/for-body

[Carl Eastlund]

You're proving that (let () ...) is necessary, which I have explicitly
agreed with since the original email, but you have not yet demonstrated
that split-for-body is necessary.  Here is the fix I have described twice
already, now explicitly put into the define-syntax-rule solution:

(define-syntax-rule (for/print/fixed clauses pre .. result)
  (for clauses
pre ...
(printf "~v\n" (let () result

Carl Eastlund


On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt  wrote:

>
> #lang racket/base
> (require (for-syntax racket/base
>  syntax/parse
>  syntax/for-body))
>
> (define-syntax (for/print/good stx)
>   (syntax-parse stx
> [(_ clauses . body)
>  (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)])
>(syntax
> (for clauses
>   pre ...
>   (printf "~v\n" (let () post ...)]))
>
> (define-syntax-rule (for/print/bad clauses pre ... result)
>   (for clauses
> pre ...
> (printf "~v\n" result)))
>
> ;; Try changing to for/print/bad:
> (for/print/good ([i 1])
>   (define (fish? v) (or (red? v) (blue? v)))
>   (begin
> (define (red? v) (eq? v 'red))
> (define (blue? v) (eq? v 'blue))
> (fish? i)))
>
>
> At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote:
> > Right, that's the issue with needing the (let () result) in my
> > define-syntax-rule version.  I still didn't need split-for-body, which
> > doesn't guarantee there are no definitions in the post ... part.  All it
> > guarantees to eliminate are #:final and #:break.
> >
> > Carl Eastlund
> >
> >
> > On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt 
> wrote:
> >
> > > The issue is `begin` splicing. The `result` form could be a `begin`
> > > form that contains definitions that are referenced by a preceding
> > > forms.
> > >
> > > For example, given
> > >
> > >  (define (fish? v) (or (red? v) (blue? v)))
> > >  (begin
> > >   (define (red? v) )
> > >   (define (blue? v) )
> > >   5)
> > >
> > > With `begin` splicing, that turns into
> > >
> > >  (define (fish? v) (or (red? v) (blue? v)))
> > >  (define (red? v) )
> > >  (define (blue? v) )
> > >  5
> > >
> > > which is different than
> > >
> > >  (define (fish? v) (or (red? v) (blue? v)))
> > >  (let ()
> > >(define (red? v) )
> > >(define (blue? v) )
> > >5)
> > >
> > > At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote:
> > > > Is this function ever particularly necessary?  Its intended use
> seems to
> > > be
> > > > like so:
> > > >
> > > > (define-syntax (for/print stx)
> > > >   (syntax-parse stx
> > > > [(_ clauses . body)
> > > >  (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)])
> > > >(syntax
> > > >  (for clauses
> > > >pre ...
> > > >(printf "~v/n" (let () post ...)]))
> > > >
> > > > That way any #:break or #:final from the body ends up in pre ...,
> where
> > > the
> > > > enclosing for loop will interpret them, and post ... will only
> include
> > > > normal definitions and expressions.
> > > >
> > > > But it seems to me there's a much easier way that should always work:
> > > >
> > > > (define-syntax-rule (for/print clauses pre ... result)
> > > >   (for clauses
> > > > pre ...
> > > > (printf "~v\n" result)))
> > > >
> > > > This not only puts all #:break and #:final clauses in pre ..., it
> should
> > > > guarantee result is an expression.  Perhaps one should still write
> (let
> > > ()
> > > > result) in case result is (begin defn expr), but that's still simpler
> > > than
> > > > using split-for-body.
> > > >
> > > > My question is -- have I overlooked some clever subtlety here that
> makes
> > > > split-for-body necessary, or is it usually easier to just decompose
> pre
> > > ...
> > > > result rather than bothering with split-for-body?
> > > >
> > > > Carl Eastlund
> > > > _
> > > >   Racket Developers list:
> > > >   http://lists.racket-lang.org/dev
> > >
> > >
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] split-for-body from syntax/for-body

[Carl Eastlund]

Is this function ever particularly necessary?  Its intended use seems to be
like so:

(define-syntax (for/print stx)
  (syntax-parse stx
[(_ clauses . body)
 (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)])
   (syntax
 (for clauses
   pre ...
   (printf "~v/n" (let () post ...)]))

That way any #:break or #:final from the body ends up in pre ..., where the
enclosing for loop will interpret them, and post ... will only include
normal definitions and expressions.

But it seems to me there's a much easier way that should always work:

(define-syntax-rule (for/print clauses pre ... result)
  (for clauses
pre ...
(printf "~v\n" result)))

This not only puts all #:break and #:final clauses in pre ..., it should
guarantee result is an expression.  Perhaps one should still write (let ()
result) in case result is (begin defn expr), but that's still simpler than
using split-for-body.

My question is -- have I overlooked some clever subtlety here that makes
split-for-body necessary, or is it usually easier to just decompose pre ...
result rather than bothering with split-for-body?

Carl Eastlund
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] split-for-body from syntax/for-body

[Matthew Flatt]

Sorry that I forgot to add the `let` while turning the code you sent
into a full example. Here's another try.

#lang racket/base
(require (for-syntax racket/base
 syntax/parse
 syntax/for-body))

(define-syntax (for/print/good stx)
  (syntax-parse stx
[(_ clauses . body)
 (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)])
   (syntax
(for clauses
  pre ...
  (printf "~v\n" (let () post ...)]))

(define-syntax-rule (for/print/fixed/not clauses pre ... result)
  (for clauses
pre ...
(printf "~v\n" (let () result

(for/print/fixed/not ([i 1])
  (define (fish? v) (or (red? v) (blue? v)))
  (begin
(define (red? v) (eq? v 'red))
(define (blue? v) (eq? v 'blue))
(fish? i)))

At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote:
> You're proving that (let () ...) is necessary, which I have explicitly
> agreed with since the original email, but you have not yet demonstrated
> that split-for-body is necessary.  Here is the fix I have described twice
> already, now explicitly put into the define-syntax-rule solution:
> 
> (define-syntax-rule (for/print/fixed clauses pre .. result)
>   (for clauses
> pre ...
> (printf "~v\n" (let () result
> 
> Carl Eastlund
> 
> 
> On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt  wrote:
> 
> >
> > #lang racket/base
> > (require (for-syntax racket/base
> >  syntax/parse
> >  syntax/for-body))
> >
> > (define-syntax (for/print/good stx)
> >   (syntax-parse stx
> > [(_ clauses . body)
> >  (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)])
> >(syntax
> > (for clauses
> >   pre ...
> >   (printf "~v\n" (let () post ...)]))
> >
> > (define-syntax-rule (for/print/bad clauses pre ... result)
> >   (for clauses
> > pre ...
> > (printf "~v\n" result)))
> >
> > ;; Try changing to for/print/bad:
> > (for/print/good ([i 1])
> >   (define (fish? v) (or (red? v) (blue? v)))
> >   (begin
> > (define (red? v) (eq? v 'red))
> > (define (blue? v) (eq? v 'blue))
> > (fish? i)))
> >
> >
> > At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote:
> > > Right, that's the issue with needing the (let () result) in my
> > > define-syntax-rule version.  I still didn't need split-for-body, which
> > > doesn't guarantee there are no definitions in the post ... part.  All it
> > > guarantees to eliminate are #:final and #:break.
> > >
> > > Carl Eastlund
> > >
> > >
> > > On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt 
> > wrote:
> > >
> > > > The issue is `begin` splicing. The `result` form could be a `begin`
> > > > form that contains definitions that are referenced by a preceding
> > > > forms.
> > > >
> > > > For example, given
> > > >
> > > >  (define (fish? v) (or (red? v) (blue? v)))
> > > >  (begin
> > > >   (define (red? v) )
> > > >   (define (blue? v) )
> > > >   5)
> > > >
> > > > With `begin` splicing, that turns into
> > > >
> > > >  (define (fish? v) (or (red? v) (blue? v)))
> > > >  (define (red? v) )
> > > >  (define (blue? v) )
> > > >  5
> > > >
> > > > which is different than
> > > >
> > > >  (define (fish? v) (or (red? v) (blue? v)))
> > > >  (let ()
> > > >(define (red? v) )
> > > >(define (blue? v) )
> > > >5)
> > > >
> > > > At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote:
> > > > > Is this function ever particularly necessary?  Its intended use
> > seems to
> > > > be
> > > > > like so:
> > > > >
> > > > > (define-syntax (for/print stx)
> > > > >   (syntax-parse stx
> > > > > [(_ clauses . body)
> > > > >  (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)])
> > > > >(syntax
> > > > >  (for clauses
> > > > >pre ...
> > > > >(printf "~v/n" (let () post ...)]))
> > > > >
> > > > > That way any #:break or #:final from the body ends up in pre ...,
> > where
> > > > the
> > > > > enclosing for loop will interpret them, and post ... will only
> > include
> > > > > normal definitions and expressions.
> > > > >
> > > > > But it seems to me there's a much easier way that should always work:
> > > > >
> > > > > (define-syntax-rule (for/print clauses pre ... result)
> > > > >   (for clauses
> > > > > pre ...
> > > > > (printf "~v\n" result)))
> > > > >
> > > > > This not only puts all #:break and #:final clauses in pre ..., it
> > should
> > > > > guarantee result is an expression.  Perhaps one should still write
> > (let
> > > > ()
> > > > > result) in case result is (begin defn expr), but that's still simpler
> > > > than
> > > > > using split-for-body.
> > > > >
> > > > > My question is -- have I overlooked some clever subtlety here that
> > makes
> > > > > split-for-body necessary, or is it usually easier to just decompose
> > pre
> > > > ...
> > > > > result rather than bothering with split-for-body?
> > > > >
> > > > > Carl Eastlun

Re: [racket-dev] split-for-body from syntax/for-body

[Carl Eastlund]

Right, that's the issue with needing the (let () result) in my
define-syntax-rule version.  I still didn't need split-for-body, which
doesn't guarantee there are no definitions in the post ... part.  All it
guarantees to eliminate are #:final and #:break.

Carl Eastlund


On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt  wrote:

> The issue is `begin` splicing. The `result` form could be a `begin`
> form that contains definitions that are referenced by a preceding
> forms.
>
> For example, given
>
>  (define (fish? v) (or (red? v) (blue? v)))
>  (begin
>   (define (red? v) )
>   (define (blue? v) )
>   5)
>
> With `begin` splicing, that turns into
>
>  (define (fish? v) (or (red? v) (blue? v)))
>  (define (red? v) )
>  (define (blue? v) )
>  5
>
> which is different than
>
>  (define (fish? v) (or (red? v) (blue? v)))
>  (let ()
>(define (red? v) )
>(define (blue? v) )
>5)
>
> At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote:
> > Is this function ever particularly necessary?  Its intended use seems to
> be
> > like so:
> >
> > (define-syntax (for/print stx)
> >   (syntax-parse stx
> > [(_ clauses . body)
> >  (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)])
> >(syntax
> >  (for clauses
> >pre ...
> >(printf "~v/n" (let () post ...)]))
> >
> > That way any #:break or #:final from the body ends up in pre ..., where
> the
> > enclosing for loop will interpret them, and post ... will only include
> > normal definitions and expressions.
> >
> > But it seems to me there's a much easier way that should always work:
> >
> > (define-syntax-rule (for/print clauses pre ... result)
> >   (for clauses
> > pre ...
> > (printf "~v\n" result)))
> >
> > This not only puts all #:break and #:final clauses in pre ..., it should
> > guarantee result is an expression.  Perhaps one should still write (let
> ()
> > result) in case result is (begin defn expr), but that's still simpler
> than
> > using split-for-body.
> >
> > My question is -- have I overlooked some clever subtlety here that makes
> > split-for-body necessary, or is it usually easier to just decompose pre
> ...
> > result rather than bothering with split-for-body?
> >
> > Carl Eastlund
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] split-for-body from syntax/for-body

[Matthew Flatt]

The issue is `begin` splicing. The `result` form could be a `begin`
form that contains definitions that are referenced by a preceding
forms.

For example, given

 (define (fish? v) (or (red? v) (blue? v)))
 (begin
  (define (red? v) )
  (define (blue? v) )
  5)

With `begin` splicing, that turns into

 (define (fish? v) (or (red? v) (blue? v)))
 (define (red? v) )
 (define (blue? v) )
 5

which is different than

 (define (fish? v) (or (red? v) (blue? v)))
 (let ()
   (define (red? v) )
   (define (blue? v) )
   5)

At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote:
> Is this function ever particularly necessary?  Its intended use seems to be
> like so:
> 
> (define-syntax (for/print stx)
>   (syntax-parse stx
> [(_ clauses . body)
>  (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)])
>(syntax
>  (for clauses
>pre ...
>(printf "~v/n" (let () post ...)]))
> 
> That way any #:break or #:final from the body ends up in pre ..., where the
> enclosing for loop will interpret them, and post ... will only include
> normal definitions and expressions.
> 
> But it seems to me there's a much easier way that should always work:
> 
> (define-syntax-rule (for/print clauses pre ... result)
>   (for clauses
> pre ...
> (printf "~v\n" result)))
> 
> This not only puts all #:break and #:final clauses in pre ..., it should
> guarantee result is an expression.  Perhaps one should still write (let ()
> result) in case result is (begin defn expr), but that's still simpler than
> using split-for-body.
> 
> My question is -- have I overlooked some clever subtlety here that makes
> split-for-body necessary, or is it usually easier to just decompose pre ...
> result rather than bothering with split-for-body?
> 
> Carl Eastlund
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] split-for-body from syntax/for-body

[Carl Eastlund]

On Fri, Sep 6, 2013 at 2:43 PM, Stephen Chang  wrote:

> On Fri, Sep 6, 2013 at 2:36 PM, Carl Eastlund  wrote:
> > They have to be separate internal definition contexts in order for
> #:break
> > and #:final to be able to stop execution before the definitions
> themselves
> > get run.
>
> Hmm, ok. I guess my question was why does one need #:final and #:break
> in the body like that?
>

It's useful when the condition for loop termination and the value of the
loop body both depend on some derived computation from the sequence
elements:

(for/list ([x (in-stream S)])
  (define y (f x))
  #:break (g? y)
  (h y))

> Carl Eastlund
> >
> >
> > On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang 
> wrote:
> >>
> >> > "Among the bodys, besides stopping the iteration and preventing later
> >> > body evaluations, a #:break guard-expr or #:final guard-expr clause
> starts a
> >> > new internal-definition context."
> >>
> >> I had the same thought process as Carl. I now understand the behavior
> >> but I don't understand why it's needed? It seems kind of arbitrary
> >> since no other form allows multiple internal def contexts in the body
> >> like this. Is there a practical example?
> >>
> >> On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund  wrote:
> >> > Okay, I see what's going on here.  It's very subtle though, and
> probably
> >> > deserves some explanation in split-for-body's documentation.
> >> >
> >> > My first thought on seeing my non-fix version break here is that I can
> >> > make
> >> > split-for-body break the same way.  The problem is that my non-fix
> >> > separates
> >> > the definition of fish? from the definitions of red? and blue?, which
> it
> >> > depends on.  I can make split-for-body separate them the same way, by
> >> > putting a #:break or #:final clause in between the definition of fish?
> >> > and
> >> > the begin form.
> >> >
> >> > The problem with doing so is a subtle point about for loops that is
> only
> >> > mentioned in the last sentence of the last paragraph of the
> >> > documentation of
> >> > for itself:
> >> >
> >> >   "Among the bodys, besides stopping the iteration and preventing
> later
> >> > body
> >> > evaluations, a #:break guard-expr or #:final guard-expr clause starts
> a
> >> > new
> >> > internal-definition context."
> >> >
> >> > So that's what split-for-body is preserving, the boundaries between
> >> > internal
> >> > definition contexts.  That's not at all what I had expected it was
> >> > doing; I
> >> > had no idea the body of a for loop constituted multiple such contexts.
> >> >
> >> > Anyway, thanks for the clarification, I now understand why
> abstractions
> >> > over
> >> > for loops need to use split-for-body.
> >> >
> >> > Carl Eastlund
> >> >
> >> >
> >> > On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt 
> >> > wrote:
> >> >>
> >> >> Sorry that I forgot to add the `let` while turning the code you sent
> >> >> into a full example. Here's another try.
> >> >>
> >> >> #lang racket/base
> >> >> (require (for-syntax racket/base
> >> >>  syntax/parse
> >> >>  syntax/for-body))
> >> >>
> >> >> (define-syntax (for/print/good stx)
> >> >>   (syntax-parse stx
> >> >> [(_ clauses . body)
> >> >>  (with-syntax ([([pre ...] [post ...]) (split-for-body stx
> >> >> #'body)])
> >> >>(syntax
> >> >> (for clauses
> >> >>   pre ...
> >> >>   (printf "~v\n" (let () post ...)]))
> >> >>
> >> >> (define-syntax-rule (for/print/fixed/not clauses pre ... result)
> >> >>   (for clauses
> >> >> pre ...
> >> >> (printf "~v\n" (let () result
> >> >>
> >> >> (for/print/fixed/not ([i 1])
> >> >>   (define (fish? v) (or (red? v) (blue? v)))
> >> >>   (begin
> >> >> (define (red? v) (eq? v 'red))
> >> >> (define (blue? v) (eq? v 'blue))
> >> >> (fish? i)))
> >> >>
> >> >> At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote:
> >> >> > You're proving that (let () ...) is necessary, which I have
> >> >> > explicitly
> >> >> > agreed with since the original email, but you have not yet
> >> >> > demonstrated
> >> >> > that split-for-body is necessary.  Here is the fix I have described
> >> >> > twice
> >> >> > already, now explicitly put into the define-syntax-rule solution:
> >> >> >
> >> >> > (define-syntax-rule (for/print/fixed clauses pre .. result)
> >> >> >   (for clauses
> >> >> > pre ...
> >> >> > (printf "~v\n" (let () result
> >> >> >
> >> >> > Carl Eastlund
> >> >> >
> >> >> >
> >> >> > On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt  >
> >> >> > wrote:
> >> >> >
> >> >> > >
> >> >> > > #lang racket/base
> >> >> > > (require (for-syntax racket/base
> >> >> > >  syntax/parse
> >> >> > >  syntax/for-body))
> >> >> > >
> >> >> > > (define-syntax (for/print/good stx)
> >> >> > >   (syntax-parse stx
> >> >> > > [(_ clauses . body)
> >> >> > >  (with-syntax ([([pre ...] [post ...]) (split-for-body stx
> >> >> > > #'body)])
> >> >> > 

Re: [racket-dev] split-for-body from syntax/for-body

[Carl Eastlund]

Okay, I see what's going on here.  It's very subtle though, and probably
deserves some explanation in split-for-body's documentation.

My first thought on seeing my non-fix version break here is that I can make
split-for-body break the same way.  The problem is that my non-fix
separates the definition of fish? from the definitions of red? and blue?,
which it depends on.  I can make split-for-body separate them the same way,
by putting a #:break or #:final clause in between the definition of fish?
and the begin form.

The problem with doing so is a subtle point about for loops that is only
mentioned in the last sentence of the last paragraph of the documentation
of for itself:

  "Among the bodys, besides stopping the iteration and preventing
later bodyevaluations, a
#:break guard-expr or #:final guard-expr clause starts a new
internal-definition context."

So that's what split-for-body is preserving, the boundaries between
internal definition contexts.  That's not at all what I had expected it was
doing; I had no idea the body of a for loop constituted multiple such
contexts.

Anyway, thanks for the clarification, I now understand why abstractions
over for loops need to use split-for-body.

Carl Eastlund


On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt  wrote:

> Sorry that I forgot to add the `let` while turning the code you sent
> into a full example. Here's another try.
>
> #lang racket/base
> (require (for-syntax racket/base
>  syntax/parse
>  syntax/for-body))
>
> (define-syntax (for/print/good stx)
>   (syntax-parse stx
> [(_ clauses . body)
>  (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)])
>(syntax
> (for clauses
>   pre ...
>   (printf "~v\n" (let () post ...)]))
>
> (define-syntax-rule (for/print/fixed/not clauses pre ... result)
>   (for clauses
> pre ...
> (printf "~v\n" (let () result
>
> (for/print/fixed/not ([i 1])
>   (define (fish? v) (or (red? v) (blue? v)))
>   (begin
> (define (red? v) (eq? v 'red))
> (define (blue? v) (eq? v 'blue))
> (fish? i)))
>
> At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote:
> > You're proving that (let () ...) is necessary, which I have explicitly
> > agreed with since the original email, but you have not yet demonstrated
> > that split-for-body is necessary.  Here is the fix I have described twice
> > already, now explicitly put into the define-syntax-rule solution:
> >
> > (define-syntax-rule (for/print/fixed clauses pre .. result)
> >   (for clauses
> > pre ...
> > (printf "~v\n" (let () result
> >
> > Carl Eastlund
> >
> >
> > On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt 
> wrote:
> >
> > >
> > > #lang racket/base
> > > (require (for-syntax racket/base
> > >  syntax/parse
> > >  syntax/for-body))
> > >
> > > (define-syntax (for/print/good stx)
> > >   (syntax-parse stx
> > > [(_ clauses . body)
> > >  (with-syntax ([([pre ...] [post ...]) (split-for-body stx
> #'body)])
> > >(syntax
> > > (for clauses
> > >   pre ...
> > >   (printf "~v\n" (let () post ...)]))
> > >
> > > (define-syntax-rule (for/print/bad clauses pre ... result)
> > >   (for clauses
> > > pre ...
> > > (printf "~v\n" result)))
> > >
> > > ;; Try changing to for/print/bad:
> > > (for/print/good ([i 1])
> > >   (define (fish? v) (or (red? v) (blue? v)))
> > >   (begin
> > > (define (red? v) (eq? v 'red))
> > > (define (blue? v) (eq? v 'blue))
> > > (fish? i)))
> > >
> > >
> > > At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote:
> > > > Right, that's the issue with needing the (let () result) in my
> > > > define-syntax-rule version.  I still didn't need split-for-body,
> which
> > > > doesn't guarantee there are no definitions in the post ... part.
>  All it
> > > > guarantees to eliminate are #:final and #:break.
> > > >
> > > > Carl Eastlund
> > > >
> > > >
> > > > On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt 
> > > wrote:
> > > >
> > > > > The issue is `begin` splicing. The `result` form could be a `begin`
> > > > > form that contains definitions that are referenced by a preceding
> > > > > forms.
> > > > >
> > > > > For example, given
> > > > >
> > > > >  (define (fish? v) (or (red? v) (blue? v)))
> > > > >  (begin
> > > > >   (define (red? v) )
> > > > >   (define (blue? v) )
> > > > >   5)
> > > > >
> > > > > With `begin` splicing, that turns into
> > > > >
> > > > >  (define (fish? v) (or (red? v) (blue? v)))
> > > > >  (define (red? v) )
> > > > >  (define (blue? v) )
> > > > >  5
> > > > >
> > > > > which is different than
> > > > >
> > > > >  (define (fish? v) (or (red? v) (blue? v)))
> > > > >  (let ()
> > > > >(define (red? v) )
> > > > >(define (blue? v) )
> > > > >5)
> > > > >
> > > > > At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote:
> > > > > > Is this function ever particularly

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

[Matthew Flatt]

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  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
> >
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] tests not being run?

[Jay McCarthy]

All correct


On Fri, Sep 6, 2013 at 12:34 PM, David Vanderson
wrote:

>  Ah - thank you!  I think I finally understand how this works.  To make
> sure, I query the props like this:
>
> ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line
> pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt
> mzc -k ~s
>
> This tells DrDr to make sure the file compiles without error, but don't
> run.
>
> ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line
> pkgs/racket-pkgs/racket-test/tests/file/main.rkt
>
>
> This is empty, telling DrDr to not do anything with this file - no
> compilation, no running, no reporting.
>
> ~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line
> pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt
> props: no `drdr:command-line' property for
> "pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt"
>
> This tells DrDr to do the default action, which is "raco test ~s".
>
>
> Is this correct?
>
> Thanks,
> Dave
>
>
>
> On 09/05/2013 08:40 AM, Jay McCarthy wrote:
>
>  On Wed, Sep 4, 2013 at 1:55 PM, David Vanderson <
> david.vander...@gmail.com> wrote:
>
>>  I totally missed pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt,
>> but it looks like DrDr is running that with 'mzc -k _' - doesn't that just
>> compile it?
>>
>
>  Yes, the intention there is to run the tests individually but test that
> the "all runner" works
>
>
>>
>> There is also a file/main.rkt that runs all the file/ tests, but that
>> file doesn't show up in DrDr.
>>
>
>  That means that it is disabled, probably because it was intended to just
> run each file separately
>
>
>>
>> I'm more confused now.  Does DrDr automatically run a main.rkt file if
>> it's present?
>>
>
>  Whether DrDr runs a file is different on a file-by-file basis via the
> props database. For this file...
>
>
>
>>
>> Thanks,
>> Dave
>>
>>   On 09/04/2013 01:58 PM, Robby Findler wrote:
>>
>> I think it makes more sense to change those 'main' modules into 'test'
>> modules, but I'm not positive.
>>
>>  Robby
>>
>>
>>  On Wed, Sep 4, 2013 at 12:26 PM, David Vanderson <
>> david.vander...@gmail.com> wrote:
>>
>>> It looks to me like most of the tests in
>>> racket/pkgs/racket-pkgs/racket-test/tests/file/* are not being run by DrDr.
>>>  I think DrDr is running them with 'raco test _' while the files mostly
>>> need to be run as 'racket _'.
>>>
>>> Am I missing something?  If not, should I fix the files to be run with
>>> 'raco test _'?
>>>
>>> Thanks,
>>> Dave
>>> _
>>>  Racket Developers list:
>>>  http://lists.racket-lang.org/dev
>>>
>>
>>
>>
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>>
>>
>
>
>  --
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>
>
>


-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] split-for-body from syntax/for-body

[Stephen Chang]

> It's useful when the condition for loop termination and the value of the
> loop body both depend on some derived computation from the sequence
> elements:
>
> (for/list ([x (in-stream S)])
>   (define y (f x))
>   #:break (g? y)
>   (h y))

Ok I see, thanks. It does make things easier to read when the break
expression becomes too large to fit on one line. So is the reason why
#:when and #:unless can't be used the same way because there already
exist when and unless forms?



>> > Carl Eastlund
>> >
>> >
>> > On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang 
>> > wrote:
>> >>
>> >> > "Among the bodys, besides stopping the iteration and preventing later
>> >> > body evaluations, a #:break guard-expr or #:final guard-expr clause
>> >> > starts a
>> >> > new internal-definition context."
>> >>
>> >> I had the same thought process as Carl. I now understand the behavior
>> >> but I don't understand why it's needed? It seems kind of arbitrary
>> >> since no other form allows multiple internal def contexts in the body
>> >> like this. Is there a practical example?
>> >>
>> >> On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund  wrote:
>> >> > Okay, I see what's going on here.  It's very subtle though, and
>> >> > probably
>> >> > deserves some explanation in split-for-body's documentation.
>> >> >
>> >> > My first thought on seeing my non-fix version break here is that I
>> >> > can
>> >> > make
>> >> > split-for-body break the same way.  The problem is that my non-fix
>> >> > separates
>> >> > the definition of fish? from the definitions of red? and blue?, which
>> >> > it
>> >> > depends on.  I can make split-for-body separate them the same way, by
>> >> > putting a #:break or #:final clause in between the definition of
>> >> > fish?
>> >> > and
>> >> > the begin form.
>> >> >
>> >> > The problem with doing so is a subtle point about for loops that is
>> >> > only
>> >> > mentioned in the last sentence of the last paragraph of the
>> >> > documentation of
>> >> > for itself:
>> >> >
>> >> >   "Among the bodys, besides stopping the iteration and preventing
>> >> > later
>> >> > body
>> >> > evaluations, a #:break guard-expr or #:final guard-expr clause starts
>> >> > a
>> >> > new
>> >> > internal-definition context."
>> >> >
>> >> > So that's what split-for-body is preserving, the boundaries between
>> >> > internal
>> >> > definition contexts.  That's not at all what I had expected it was
>> >> > doing; I
>> >> > had no idea the body of a for loop constituted multiple such
>> >> > contexts.
>> >> >
>> >> > Anyway, thanks for the clarification, I now understand why
>> >> > abstractions
>> >> > over
>> >> > for loops need to use split-for-body.
>> >> >
>> >> > Carl Eastlund
>> >> >
>> >> >
>> >> > On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt 
>> >> > wrote:
>> >> >>
>> >> >> Sorry that I forgot to add the `let` while turning the code you sent
>> >> >> into a full example. Here's another try.
>> >> >>
>> >> >> #lang racket/base
>> >> >> (require (for-syntax racket/base
>> >> >>  syntax/parse
>> >> >>  syntax/for-body))
>> >> >>
>> >> >> (define-syntax (for/print/good stx)
>> >> >>   (syntax-parse stx
>> >> >> [(_ clauses . body)
>> >> >>  (with-syntax ([([pre ...] [post ...]) (split-for-body stx
>> >> >> #'body)])
>> >> >>(syntax
>> >> >> (for clauses
>> >> >>   pre ...
>> >> >>   (printf "~v\n" (let () post ...)]))
>> >> >>
>> >> >> (define-syntax-rule (for/print/fixed/not clauses pre ... result)
>> >> >>   (for clauses
>> >> >> pre ...
>> >> >> (printf "~v\n" (let () result
>> >> >>
>> >> >> (for/print/fixed/not ([i 1])
>> >> >>   (define (fish? v) (or (red? v) (blue? v)))
>> >> >>   (begin
>> >> >> (define (red? v) (eq? v 'red))
>> >> >> (define (blue? v) (eq? v 'blue))
>> >> >> (fish? i)))
>> >> >>
>> >> >> At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote:
>> >> >> > You're proving that (let () ...) is necessary, which I have
>> >> >> > explicitly
>> >> >> > agreed with since the original email, but you have not yet
>> >> >> > demonstrated
>> >> >> > that split-for-body is necessary.  Here is the fix I have
>> >> >> > described
>> >> >> > twice
>> >> >> > already, now explicitly put into the define-syntax-rule solution:
>> >> >> >
>> >> >> > (define-syntax-rule (for/print/fixed clauses pre .. result)
>> >> >> >   (for clauses
>> >> >> > pre ...
>> >> >> > (printf "~v\n" (let () result
>> >> >> >
>> >> >> > Carl Eastlund
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt
>> >> >> > 
>> >> >> > wrote:
>> >> >> >
>> >> >> > >
>> >> >> > > #lang racket/base
>> >> >> > > (require (for-syntax racket/base
>> >> >> > >  syntax/parse
>> >> >> > >  syntax/for-body))
>> >> >> > >
>> >> >> > > (define-syntax (for/print/good stx)
>> >> >> > >   (syntax-parse stx
>> >> >> > > [(_ clauses . body)
>> >> >> > >  (with-syntax ([([pr

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

[Stephen Chang]

On Fri, Sep 6, 2013 at 7:54 AM, Matthew Flatt  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
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] split-for-body from syntax/for-body

[Stephen Chang]

On Fri, Sep 6, 2013 at 2:36 PM, Carl Eastlund  wrote:
> They have to be separate internal definition contexts in order for #:break
> and #:final to be able to stop execution before the definitions themselves
> get run.

Hmm, ok. I guess my question was why does one need #:final and #:break
in the body like that?




> Carl Eastlund
>
>
> On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang  wrote:
>>
>> > "Among the bodys, besides stopping the iteration and preventing later
>> > body evaluations, a #:break guard-expr or #:final guard-expr clause starts 
>> > a
>> > new internal-definition context."
>>
>> I had the same thought process as Carl. I now understand the behavior
>> but I don't understand why it's needed? It seems kind of arbitrary
>> since no other form allows multiple internal def contexts in the body
>> like this. Is there a practical example?
>>
>> On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund  wrote:
>> > Okay, I see what's going on here.  It's very subtle though, and probably
>> > deserves some explanation in split-for-body's documentation.
>> >
>> > My first thought on seeing my non-fix version break here is that I can
>> > make
>> > split-for-body break the same way.  The problem is that my non-fix
>> > separates
>> > the definition of fish? from the definitions of red? and blue?, which it
>> > depends on.  I can make split-for-body separate them the same way, by
>> > putting a #:break or #:final clause in between the definition of fish?
>> > and
>> > the begin form.
>> >
>> > The problem with doing so is a subtle point about for loops that is only
>> > mentioned in the last sentence of the last paragraph of the
>> > documentation of
>> > for itself:
>> >
>> >   "Among the bodys, besides stopping the iteration and preventing later
>> > body
>> > evaluations, a #:break guard-expr or #:final guard-expr clause starts a
>> > new
>> > internal-definition context."
>> >
>> > So that's what split-for-body is preserving, the boundaries between
>> > internal
>> > definition contexts.  That's not at all what I had expected it was
>> > doing; I
>> > had no idea the body of a for loop constituted multiple such contexts.
>> >
>> > Anyway, thanks for the clarification, I now understand why abstractions
>> > over
>> > for loops need to use split-for-body.
>> >
>> > Carl Eastlund
>> >
>> >
>> > On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt 
>> > wrote:
>> >>
>> >> Sorry that I forgot to add the `let` while turning the code you sent
>> >> into a full example. Here's another try.
>> >>
>> >> #lang racket/base
>> >> (require (for-syntax racket/base
>> >>  syntax/parse
>> >>  syntax/for-body))
>> >>
>> >> (define-syntax (for/print/good stx)
>> >>   (syntax-parse stx
>> >> [(_ clauses . body)
>> >>  (with-syntax ([([pre ...] [post ...]) (split-for-body stx
>> >> #'body)])
>> >>(syntax
>> >> (for clauses
>> >>   pre ...
>> >>   (printf "~v\n" (let () post ...)]))
>> >>
>> >> (define-syntax-rule (for/print/fixed/not clauses pre ... result)
>> >>   (for clauses
>> >> pre ...
>> >> (printf "~v\n" (let () result
>> >>
>> >> (for/print/fixed/not ([i 1])
>> >>   (define (fish? v) (or (red? v) (blue? v)))
>> >>   (begin
>> >> (define (red? v) (eq? v 'red))
>> >> (define (blue? v) (eq? v 'blue))
>> >> (fish? i)))
>> >>
>> >> At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote:
>> >> > You're proving that (let () ...) is necessary, which I have
>> >> > explicitly
>> >> > agreed with since the original email, but you have not yet
>> >> > demonstrated
>> >> > that split-for-body is necessary.  Here is the fix I have described
>> >> > twice
>> >> > already, now explicitly put into the define-syntax-rule solution:
>> >> >
>> >> > (define-syntax-rule (for/print/fixed clauses pre .. result)
>> >> >   (for clauses
>> >> > pre ...
>> >> > (printf "~v\n" (let () result
>> >> >
>> >> > Carl Eastlund
>> >> >
>> >> >
>> >> > On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt 
>> >> > wrote:
>> >> >
>> >> > >
>> >> > > #lang racket/base
>> >> > > (require (for-syntax racket/base
>> >> > >  syntax/parse
>> >> > >  syntax/for-body))
>> >> > >
>> >> > > (define-syntax (for/print/good stx)
>> >> > >   (syntax-parse stx
>> >> > > [(_ clauses . body)
>> >> > >  (with-syntax ([([pre ...] [post ...]) (split-for-body stx
>> >> > > #'body)])
>> >> > >(syntax
>> >> > > (for clauses
>> >> > >   pre ...
>> >> > >   (printf "~v\n" (let () post ...)]))
>> >> > >
>> >> > > (define-syntax-rule (for/print/bad clauses pre ... result)
>> >> > >   (for clauses
>> >> > > pre ...
>> >> > > (printf "~v\n" result)))
>> >> > >
>> >> > > ;; Try changing to for/print/bad:
>> >> > > (for/print/good ([i 1])
>> >> > >   (define (fish? v) (or (red? v) (blue? v)))
>> >> > >   (begin
>> >> > > (define (red? v) (eq? v 'red))
>> >> > > (define (blue? v) (eq

Re: [racket-dev] split-for-body from syntax/for-body

[Carl Eastlund]

They have to be separate internal definition contexts in order for #:break
and #:final to be able to stop execution before the definitions themselves
get run.

Carl Eastlund


On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang  wrote:

> > "Among the bodys, besides stopping the iteration and preventing later
> body evaluations, a #:break guard-expr or #:final guard-expr clause starts
> a new internal-definition context."
>
> I had the same thought process as Carl. I now understand the behavior
> but I don't understand why it's needed? It seems kind of arbitrary
> since no other form allows multiple internal def contexts in the body
> like this. Is there a practical example?
>
> On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund  wrote:
> > Okay, I see what's going on here.  It's very subtle though, and probably
> > deserves some explanation in split-for-body's documentation.
> >
> > My first thought on seeing my non-fix version break here is that I can
> make
> > split-for-body break the same way.  The problem is that my non-fix
> separates
> > the definition of fish? from the definitions of red? and blue?, which it
> > depends on.  I can make split-for-body separate them the same way, by
> > putting a #:break or #:final clause in between the definition of fish?
> and
> > the begin form.
> >
> > The problem with doing so is a subtle point about for loops that is only
> > mentioned in the last sentence of the last paragraph of the
> documentation of
> > for itself:
> >
> >   "Among the bodys, besides stopping the iteration and preventing later
> body
> > evaluations, a #:break guard-expr or #:final guard-expr clause starts a
> new
> > internal-definition context."
> >
> > So that's what split-for-body is preserving, the boundaries between
> internal
> > definition contexts.  That's not at all what I had expected it was
> doing; I
> > had no idea the body of a for loop constituted multiple such contexts.
> >
> > Anyway, thanks for the clarification, I now understand why abstractions
> over
> > for loops need to use split-for-body.
> >
> > Carl Eastlund
> >
> >
> > On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt 
> wrote:
> >>
> >> Sorry that I forgot to add the `let` while turning the code you sent
> >> into a full example. Here's another try.
> >>
> >> #lang racket/base
> >> (require (for-syntax racket/base
> >>  syntax/parse
> >>  syntax/for-body))
> >>
> >> (define-syntax (for/print/good stx)
> >>   (syntax-parse stx
> >> [(_ clauses . body)
> >>  (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)])
> >>(syntax
> >> (for clauses
> >>   pre ...
> >>   (printf "~v\n" (let () post ...)]))
> >>
> >> (define-syntax-rule (for/print/fixed/not clauses pre ... result)
> >>   (for clauses
> >> pre ...
> >> (printf "~v\n" (let () result
> >>
> >> (for/print/fixed/not ([i 1])
> >>   (define (fish? v) (or (red? v) (blue? v)))
> >>   (begin
> >> (define (red? v) (eq? v 'red))
> >> (define (blue? v) (eq? v 'blue))
> >> (fish? i)))
> >>
> >> At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote:
> >> > You're proving that (let () ...) is necessary, which I have explicitly
> >> > agreed with since the original email, but you have not yet
> demonstrated
> >> > that split-for-body is necessary.  Here is the fix I have described
> >> > twice
> >> > already, now explicitly put into the define-syntax-rule solution:
> >> >
> >> > (define-syntax-rule (for/print/fixed clauses pre .. result)
> >> >   (for clauses
> >> > pre ...
> >> > (printf "~v\n" (let () result
> >> >
> >> > Carl Eastlund
> >> >
> >> >
> >> > On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt 
> >> > wrote:
> >> >
> >> > >
> >> > > #lang racket/base
> >> > > (require (for-syntax racket/base
> >> > >  syntax/parse
> >> > >  syntax/for-body))
> >> > >
> >> > > (define-syntax (for/print/good stx)
> >> > >   (syntax-parse stx
> >> > > [(_ clauses . body)
> >> > >  (with-syntax ([([pre ...] [post ...]) (split-for-body stx
> >> > > #'body)])
> >> > >(syntax
> >> > > (for clauses
> >> > >   pre ...
> >> > >   (printf "~v\n" (let () post ...)]))
> >> > >
> >> > > (define-syntax-rule (for/print/bad clauses pre ... result)
> >> > >   (for clauses
> >> > > pre ...
> >> > > (printf "~v\n" result)))
> >> > >
> >> > > ;; Try changing to for/print/bad:
> >> > > (for/print/good ([i 1])
> >> > >   (define (fish? v) (or (red? v) (blue? v)))
> >> > >   (begin
> >> > > (define (red? v) (eq? v 'red))
> >> > > (define (blue? v) (eq? v 'blue))
> >> > > (fish? i)))
> >> > >
> >> > >
> >> > > At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote:
> >> > > > Right, that's the issue with needing the (let () result) in my
> >> > > > define-syntax-rule version.  I still didn't need split-for-body,
> >> > > > which
> >> > > > doesn't guarantee there are no definitions

Re: [racket-dev] tests not being run?

[David Vanderson]

Ah - thank you!  I think I finally understand how this works.  To make 
sure, I query the props like this:


~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line 
pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt

mzc -k ~s

This tells DrDr to make sure the file compiles without error, but don't run.

~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line 
pkgs/racket-pkgs/racket-test/tests/file/main.rkt



This is empty, telling DrDr to not do anything with this file - no 
compilation, no running, no reporting.


~/apps/racket$ ./pkgs/plt-services/meta/props get drdr:command-line 
pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt
props: no `drdr:command-line' property for 
"pkgs/racket-pkgs/racket-test/tests/file/sha1.rkt"


This tells DrDr to do the default action, which is "raco test ~s".


Is this correct?

Thanks,
Dave


On 09/05/2013 08:40 AM, Jay McCarthy wrote:
On Wed, Sep 4, 2013 at 1:55 PM, David Vanderson 
mailto:david.vander...@gmail.com>> wrote:


I totally missed
pkgs/racket-pkgs/racket-test/tests/run-automated-tests.rkt, but it
looks like DrDr is running that with 'mzc -k _' - doesn't that
just compile it?


Yes, the intention there is to run the tests individually but test 
that the "all runner" works



There is also a file/main.rkt that runs all the file/ tests, but
that file doesn't show up in DrDr.


That means that it is disabled, probably because it was intended to 
just run each file separately



I'm more confused now.  Does DrDr automatically run a main.rkt
file if it's present?


Whether DrDr runs a file is different on a file-by-file basis via the 
props database. For this file...



Thanks,
Dave

On 09/04/2013 01:58 PM, Robby Findler wrote:

I think it makes more sense to change those 'main' modules into
'test' modules, but I'm not positive.

Robby


On Wed, Sep 4, 2013 at 12:26 PM, David Vanderson
mailto:david.vander...@gmail.com>> wrote:

It looks to me like most of the tests in
racket/pkgs/racket-pkgs/racket-test/tests/file/* are not
being run by DrDr.  I think DrDr is running them with 'raco
test _' while the files mostly need to be run as 'racket _'.

Am I missing something?  If not, should I fix the files to be
run with 'raco test _'?

Thanks,
Dave
_
 Racket Developers list:
http://lists.racket-lang.org/dev





_
  Racket Developers list:
http://lists.racket-lang.org/dev




--
Jay McCarthy mailto:j...@cs.byu.edu>>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay 

"The glory of God is Intelligence" - D&C 93


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] split-for-body from syntax/for-body

[Stephen Chang]

> "Among the bodys, besides stopping the iteration and preventing later body 
> evaluations, a #:break guard-expr or #:final guard-expr clause starts a new 
> internal-definition context."

I had the same thought process as Carl. I now understand the behavior
but I don't understand why it's needed? It seems kind of arbitrary
since no other form allows multiple internal def contexts in the body
like this. Is there a practical example?

On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund  wrote:
> Okay, I see what's going on here.  It's very subtle though, and probably
> deserves some explanation in split-for-body's documentation.
>
> My first thought on seeing my non-fix version break here is that I can make
> split-for-body break the same way.  The problem is that my non-fix separates
> the definition of fish? from the definitions of red? and blue?, which it
> depends on.  I can make split-for-body separate them the same way, by
> putting a #:break or #:final clause in between the definition of fish? and
> the begin form.
>
> The problem with doing so is a subtle point about for loops that is only
> mentioned in the last sentence of the last paragraph of the documentation of
> for itself:
>
>   "Among the bodys, besides stopping the iteration and preventing later body
> evaluations, a #:break guard-expr or #:final guard-expr clause starts a new
> internal-definition context."
>
> So that's what split-for-body is preserving, the boundaries between internal
> definition contexts.  That's not at all what I had expected it was doing; I
> had no idea the body of a for loop constituted multiple such contexts.
>
> Anyway, thanks for the clarification, I now understand why abstractions over
> for loops need to use split-for-body.
>
> Carl Eastlund
>
>
> On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt  wrote:
>>
>> Sorry that I forgot to add the `let` while turning the code you sent
>> into a full example. Here's another try.
>>
>> #lang racket/base
>> (require (for-syntax racket/base
>>  syntax/parse
>>  syntax/for-body))
>>
>> (define-syntax (for/print/good stx)
>>   (syntax-parse stx
>> [(_ clauses . body)
>>  (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)])
>>(syntax
>> (for clauses
>>   pre ...
>>   (printf "~v\n" (let () post ...)]))
>>
>> (define-syntax-rule (for/print/fixed/not clauses pre ... result)
>>   (for clauses
>> pre ...
>> (printf "~v\n" (let () result
>>
>> (for/print/fixed/not ([i 1])
>>   (define (fish? v) (or (red? v) (blue? v)))
>>   (begin
>> (define (red? v) (eq? v 'red))
>> (define (blue? v) (eq? v 'blue))
>> (fish? i)))
>>
>> At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote:
>> > You're proving that (let () ...) is necessary, which I have explicitly
>> > agreed with since the original email, but you have not yet demonstrated
>> > that split-for-body is necessary.  Here is the fix I have described
>> > twice
>> > already, now explicitly put into the define-syntax-rule solution:
>> >
>> > (define-syntax-rule (for/print/fixed clauses pre .. result)
>> >   (for clauses
>> > pre ...
>> > (printf "~v\n" (let () result
>> >
>> > Carl Eastlund
>> >
>> >
>> > On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt 
>> > wrote:
>> >
>> > >
>> > > #lang racket/base
>> > > (require (for-syntax racket/base
>> > >  syntax/parse
>> > >  syntax/for-body))
>> > >
>> > > (define-syntax (for/print/good stx)
>> > >   (syntax-parse stx
>> > > [(_ clauses . body)
>> > >  (with-syntax ([([pre ...] [post ...]) (split-for-body stx
>> > > #'body)])
>> > >(syntax
>> > > (for clauses
>> > >   pre ...
>> > >   (printf "~v\n" (let () post ...)]))
>> > >
>> > > (define-syntax-rule (for/print/bad clauses pre ... result)
>> > >   (for clauses
>> > > pre ...
>> > > (printf "~v\n" result)))
>> > >
>> > > ;; Try changing to for/print/bad:
>> > > (for/print/good ([i 1])
>> > >   (define (fish? v) (or (red? v) (blue? v)))
>> > >   (begin
>> > > (define (red? v) (eq? v 'red))
>> > > (define (blue? v) (eq? v 'blue))
>> > > (fish? i)))
>> > >
>> > >
>> > > At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote:
>> > > > Right, that's the issue with needing the (let () result) in my
>> > > > define-syntax-rule version.  I still didn't need split-for-body,
>> > > > which
>> > > > doesn't guarantee there are no definitions in the post ... part.
>> > > > All it
>> > > > guarantees to eliminate are #:final and #:break.
>> > > >
>> > > > Carl Eastlund
>> > > >
>> > > >
>> > > > On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt 
>> > > wrote:
>> > > >
>> > > > > The issue is `begin` splicing. The `result` form could be a
>> > > > > `begin`
>> > > > > form that contains definitions that are referenced by a preceding
>> > > > > forms.
>> > > > >
>> > > > > For example, given
>> > > > >
>> > > > >  (define (fish

Re: [racket-dev] split-for-body from syntax/for-body

[Matthew Flatt]

#lang racket/base
(require (for-syntax racket/base
 syntax/parse
 syntax/for-body))

(define-syntax (for/print/good stx)
  (syntax-parse stx
[(_ clauses . body)
 (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)])
   (syntax
(for clauses
  pre ...
  (printf "~v\n" (let () post ...)]))

(define-syntax-rule (for/print/bad clauses pre ... result)
  (for clauses
pre ...
(printf "~v\n" result)))

;; Try changing to for/print/bad:
(for/print/good ([i 1])
  (define (fish? v) (or (red? v) (blue? v)))
  (begin
(define (red? v) (eq? v 'red))
(define (blue? v) (eq? v 'blue))
(fish? i)))


At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote:
> Right, that's the issue with needing the (let () result) in my
> define-syntax-rule version.  I still didn't need split-for-body, which
> doesn't guarantee there are no definitions in the post ... part.  All it
> guarantees to eliminate are #:final and #:break.
> 
> Carl Eastlund
> 
> 
> On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt  wrote:
> 
> > The issue is `begin` splicing. The `result` form could be a `begin`
> > form that contains definitions that are referenced by a preceding
> > forms.
> >
> > For example, given
> >
> >  (define (fish? v) (or (red? v) (blue? v)))
> >  (begin
> >   (define (red? v) )
> >   (define (blue? v) )
> >   5)
> >
> > With `begin` splicing, that turns into
> >
> >  (define (fish? v) (or (red? v) (blue? v)))
> >  (define (red? v) )
> >  (define (blue? v) )
> >  5
> >
> > which is different than
> >
> >  (define (fish? v) (or (red? v) (blue? v)))
> >  (let ()
> >(define (red? v) )
> >(define (blue? v) )
> >5)
> >
> > At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote:
> > > Is this function ever particularly necessary?  Its intended use seems to
> > be
> > > like so:
> > >
> > > (define-syntax (for/print stx)
> > >   (syntax-parse stx
> > > [(_ clauses . body)
> > >  (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)])
> > >(syntax
> > >  (for clauses
> > >pre ...
> > >(printf "~v/n" (let () post ...)]))
> > >
> > > That way any #:break or #:final from the body ends up in pre ..., where
> > the
> > > enclosing for loop will interpret them, and post ... will only include
> > > normal definitions and expressions.
> > >
> > > But it seems to me there's a much easier way that should always work:
> > >
> > > (define-syntax-rule (for/print clauses pre ... result)
> > >   (for clauses
> > > pre ...
> > > (printf "~v\n" result)))
> > >
> > > This not only puts all #:break and #:final clauses in pre ..., it should
> > > guarantee result is an expression.  Perhaps one should still write (let
> > ()
> > > result) in case result is (begin defn expr), but that's still simpler
> > than
> > > using split-for-body.
> > >
> > > My question is -- have I overlooked some clever subtlety here that makes
> > > split-for-body necessary, or is it usually easier to just decompose pre
> > ...
> > > result rather than bothering with split-for-body?
> > >
> > > Carl Eastlund
> > > _
> > >   Racket Developers list:
> > >   http://lists.racket-lang.org/dev
> >
> >
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Module Browser not a plugin/tool

[Stephen De Gabrielle]

thanks.
http://planet.racket-lang.org/display.ss?package=insert-large-letters.plt&owner=spdegabrielle


--
Stephen De Gabrielle 



On Fri, Sep 6, 2013 at 2:35 PM, Robby Findler
wrote:

> I got the attachments, FWIW. Probably best, however, if someone were to
> submit a pull request with the code still in TR and with the appropriate
> removal of the current implementation. Otherwise, I think it has served its
> purpose as a learning experiment and that's seems excellent.
>
> Robby
>
>
> On Fri, Sep 6, 2013 at 8:32 AM, Stephen De Gabrielle <
> stephen.degabrie...@acm.org> wrote:
>
>> Ugh - the list scrubbed my attachments.  I'm guessing my options are to
>> submit pull request or make a planet package.
>> s.
>>
>>
>>
>> On Fri, Sep 6, 2013 at 2:00 PM, Stephen De Gabrielle <
>> stephen.degabrie...@acm.org> wrote:
>>
>>> Hi,
>>>
>>> I just tried making a instance of insert-large-letters as a tool. I just
>>> copied the code and added the tools stuff.
>>>
>>> Seemed to work OK, but
>>> - I turned it into normal racket as I didn't have time to learn typed
>>> racket.
>>> - I'm not confident enough with the core of DrRacket to remove the
>>> 'insert-large-letters' code without messing something else up.
>>>
>>> I'm doing this as a learning exercise for the tools, but I may try
>>> get-defns[1] and module browser[2] at some point.
>>>
>>> [1] personally not a big fan of drop down menus - I like the tree thingy
>>> you see in other IDEs
>>> [2] to make Dr start quicker on slow machines.
>>>
>>> Cheers,
>>>
>>> Stephen
>>>
>>>
>>> --
>>> Stephen De Gabrielle 
>>>
>>>
>>>
>>> On Sat, Aug 31, 2013 at 11:32 PM, Robby Findler <
>>> ro...@eecs.northwestern.edu> wrote:
>>>
 I'm not sure the module browser was before the plugin api, but probably
 it wasn't. I think all three of those could be tools, but it is an accident
 of history (and of who implemented them...) that they aren't. Probably they
 should be. We might even save some startup time by disabling the module
 browser.

 Robby


 On Sat, Aug 31, 2013 at 1:43 PM, Stephen De Gabrielle <
 stephen.degabrie...@acm.org> wrote:

> Hi,
> looking through the source I've noticed the module browser is not a
> tool, I'm guessing this is because it preceded the introduction of the
> plugins mechanism?
>
> Check Syntax is a tool, but insert-large-letters.rkt and get-defn's
>  are not?
>
> is there a defined criteria? or is the arrangement historic/
>
> Kind Regards,
>
> Stephen
>
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>

>>>
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Module Browser not a plugin/tool

[Robby Findler]

I got the attachments, FWIW. Probably best, however, if someone were to
submit a pull request with the code still in TR and with the appropriate
removal of the current implementation. Otherwise, I think it has served its
purpose as a learning experiment and that's seems excellent.

Robby


On Fri, Sep 6, 2013 at 8:32 AM, Stephen De Gabrielle <
stephen.degabrie...@acm.org> wrote:

> Ugh - the list scrubbed my attachments.  I'm guessing my options are to
> submit pull request or make a planet package.
> s.
>
>
>
> On Fri, Sep 6, 2013 at 2:00 PM, Stephen De Gabrielle <
> stephen.degabrie...@acm.org> wrote:
>
>> Hi,
>>
>> I just tried making a instance of insert-large-letters as a tool. I just
>> copied the code and added the tools stuff.
>>
>> Seemed to work OK, but
>> - I turned it into normal racket as I didn't have time to learn typed
>> racket.
>> - I'm not confident enough with the core of DrRacket to remove the
>> 'insert-large-letters' code without messing something else up.
>>
>> I'm doing this as a learning exercise for the tools, but I may try
>> get-defns[1] and module browser[2] at some point.
>>
>> [1] personally not a big fan of drop down menus - I like the tree thingy
>> you see in other IDEs
>> [2] to make Dr start quicker on slow machines.
>>
>> Cheers,
>>
>> Stephen
>>
>>
>> --
>> Stephen De Gabrielle 
>>
>>
>>
>> On Sat, Aug 31, 2013 at 11:32 PM, Robby Findler <
>> ro...@eecs.northwestern.edu> wrote:
>>
>>> I'm not sure the module browser was before the plugin api, but probably
>>> it wasn't. I think all three of those could be tools, but it is an accident
>>> of history (and of who implemented them...) that they aren't. Probably they
>>> should be. We might even save some startup time by disabling the module
>>> browser.
>>>
>>> Robby
>>>
>>>
>>> On Sat, Aug 31, 2013 at 1:43 PM, Stephen De Gabrielle <
>>> stephen.degabrie...@acm.org> wrote:
>>>
 Hi,
 looking through the source I've noticed the module browser is not a
 tool, I'm guessing this is because it preceded the introduction of the
 plugins mechanism?

 Check Syntax is a tool, but insert-large-letters.rkt and get-defn's
  are not?

 is there a defined criteria? or is the arrangement historic/

 Kind Regards,

 Stephen


 _
   Racket Developers list:
   http://lists.racket-lang.org/dev


>>>
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Module Browser not a plugin/tool

[Stephen De Gabrielle]

Ugh - the list scrubbed my attachments.  I'm guessing my options are to
submit pull request or make a planet package.
s.



On Fri, Sep 6, 2013 at 2:00 PM, Stephen De Gabrielle <
stephen.degabrie...@acm.org> wrote:

> Hi,
>
> I just tried making a instance of insert-large-letters as a tool. I just
> copied the code and added the tools stuff.
>
> Seemed to work OK, but
> - I turned it into normal racket as I didn't have time to learn typed
> racket.
> - I'm not confident enough with the core of DrRacket to remove the
> 'insert-large-letters' code without messing something else up.
>
> I'm doing this as a learning exercise for the tools, but I may try
> get-defns[1] and module browser[2] at some point.
>
> [1] personally not a big fan of drop down menus - I like the tree thingy
> you see in other IDEs
> [2] to make Dr start quicker on slow machines.
>
> Cheers,
>
> Stephen
>
>
> --
> Stephen De Gabrielle 
>
>
>
> On Sat, Aug 31, 2013 at 11:32 PM, Robby Findler <
> ro...@eecs.northwestern.edu> wrote:
>
>> I'm not sure the module browser was before the plugin api, but probably
>> it wasn't. I think all three of those could be tools, but it is an accident
>> of history (and of who implemented them...) that they aren't. Probably they
>> should be. We might even save some startup time by disabling the module
>> browser.
>>
>> Robby
>>
>>
>> On Sat, Aug 31, 2013 at 1:43 PM, Stephen De Gabrielle <
>> stephen.degabrie...@acm.org> wrote:
>>
>>> Hi,
>>> looking through the source I've noticed the module browser is not a
>>> tool, I'm guessing this is because it preceded the introduction of the
>>> plugins mechanism?
>>>
>>> Check Syntax is a tool, but insert-large-letters.rkt and get-defn's  are
>>> not?
>>>
>>> is there a defined criteria? or is the arrangement historic/
>>>
>>> Kind Regards,
>>>
>>> Stephen
>>>
>>>
>>> _
>>>   Racket Developers list:
>>>   http://lists.racket-lang.org/dev
>>>
>>>
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Module Browser not a plugin/tool

[Stephen De Gabrielle]

Hi,

I just tried making a instance of insert-large-letters as a tool. I just
copied the code and added the tools stuff.

Seemed to work OK, but
- I turned it into normal racket as I didn't have time to learn typed
racket.
- I'm not confident enough with the core of DrRacket to remove the
'insert-large-letters' code without messing something else up.

I'm doing this as a learning exercise for the tools, but I may try
get-defns[1] and module browser[2] at some point.

[1] personally not a big fan of drop down menus - I like the tree thingy
you see in other IDEs
[2] to make Dr start quicker on slow machines.

Cheers,

Stephen


--
Stephen De Gabrielle 



On Sat, Aug 31, 2013 at 11:32 PM, Robby Findler  wrote:

> I'm not sure the module browser was before the plugin api, but probably it
> wasn't. I think all three of those could be tools, but it is an accident of
> history (and of who implemented them...) that they aren't. Probably they
> should be. We might even save some startup time by disabling the module
> browser.
>
> Robby
>
>
> On Sat, Aug 31, 2013 at 1:43 PM, Stephen De Gabrielle <
> stephen.degabrie...@acm.org> wrote:
>
>> Hi,
>> looking through the source I've noticed the module browser is not a tool,
>> I'm guessing this is because it preceded the introduction of the plugins
>> mechanism?
>>
>> Check Syntax is a tool, but insert-large-letters.rkt and get-defn's  are
>> not?
>>
>> is there a defined criteria? or is the arrangement historic/
>>
>> Kind Regards,
>>
>> Stephen
>>
>>
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>>
>>
>


bitmap-message.rkt
Description: Binary data


info.rkt
Description: Binary data


tool.rkt
Description: Binary data
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

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

[Matthew Flatt]

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.

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

_
  Racket Developers list:
  http://lists.racket-lang.org/dev