[racket-dev] Can't log in to pkg.racket-lang.org

2014-01-26 Thread Carl Eastlund
I've put in my email and password, but clicking Log In does nothing.
Neither does pressing enter.  Anyone else seeing this behavior, or know
what the problem is?

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


Re: [racket-dev] Can't log in to pkg.racket-lang.org

2014-01-26 Thread Carl Eastlund
Thanks, that worked.

Carl Eastlund


On Mon, Jan 27, 2014 at 12:18 AM, Kazuhiro HISHINUMA k...@cs.meiji.ac.jpwrote:

 Me too.  I think your browser maybe blocks SSL certificate of
 https://pkg.racket-lang.org/.
 Try to access https://pkg.racket-lang.org/ and approve its certificate.


 (2014/01/27 12:49), Carl Eastlund wrote:

 I've put in my email and password, but clicking Log In does nothing.
 Neither does pressing enter.  Anyone else seeing this behavior, or know
 what the problem is?

 Carl Eastlund


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



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


Re: [racket-dev] Pre-Release Checklist for v6.0, Second Call

2014-01-05 Thread Carl Eastlund
On Sun, Dec 29, 2013 at 1:57 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:

 * Carl Eastlund c...@ccs.neu.edu
   - Dracula Tests (confirm that Dracula runs from PLaneT)


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


Re: [racket-dev] Generics updates

2013-10-02 Thread Carl Eastlund
Short(ish) answer until I get reliable internet in my new apartment --
gen:set is modeled after gen:dict.  I don't want us to have a new design
for each interface.  Because methods are optional, we get by with one name
for one or more related subinterfaces.  That's the principle by which I
justified set-add and set-add! In one interface.

And if we separate them, we need one interface with just queries, then four
more for add, remove, add!, and remove!, at the very least.  It's a messy
direction to go in.

Carl Eastlund

--
WARNING!  Poorly-typed cell phone email precedes.
On Oct 2, 2013 4:35 PM, Jay McCarthy jay.mccar...@gmail.com wrote:

 I agree. I think the important thing with generics is unlike mpair?
 the set? predicate only necessarily implies that the methods are
 available (which is the source of my original complaint). We need to
 design the meaning of predicates just like we design the interface. I
 think that if we want mset to be a set then set? cannot imply
 immutable? but since that is a valuable property, it is worth
 designing a predicate that gives it, if only as a human thing.

 Jay

 On Wed, Oct 2, 2013 at 2:29 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  That sounds right.
 
  But just in case there is any confusion on the larger point: predicates
 as
  way we check properties to ensure good properties of our abstractions is
 one
  of the important things that we have mostly gotten right in Racket.
  Chaperones, separate pair? and mpair? predicates, and presumably lots of
  other stuff are the way they are for this kind of reason.
 
  Robby
 
 
  On Wed, Oct 2, 2013 at 3:21 PM, Jay McCarthy jay.mccar...@gmail.com
 wrote:
 
  Even if we were to remove set-add! from gen:set and not great gen:mset
  then that would not be a vaild property. Generics are a lower bound on
  the interface, not an upper bound, so there could be other functions
  on the data structure that implement mutation. For instance, a gen:set
  could be made for an external resource that was set-like.
 
  I think what you want is something like gen:fset that has no methods,
  but is used for set authors to tag their set as having this property
  for the benefit of consumers (which cannot be enforced.) Your library
  would then consume fsets and not sets.
 
  Jay
 
 
  On Wed, Oct 2, 2013 at 2:09 PM, Robby Findler
  ro...@eecs.northwestern.edu wrote:
   If we do go this way, we should be careful about the subtyping
   relationship
   since we want a predicate that means will not be mutated and I can
 rely
   on
   that to reason about my library's behavior and if mutable sets are a
   sub-thing of immutable ones, we might lose that (depending on how
 things
   are
   set up).
  
   Robby
  
  
   On Wed, Oct 2, 2013 at 2:57 PM, Jay McCarthy jay.mccar...@gmail.com
   wrote:
  
   No. Mutable sets would implement gen:set and then just have a few
 more
   methods in the gen:mset interface. Structs can implement any number
 of
   generics.
  
   Jay
  
   On Wed, Oct 2, 2013 at 1:31 PM, J. Ian Johnson i...@ccs.neu.edu
   wrote:
This means I can't interchange between mutable and immutable sets
 for
my
functions that only need to read generic sets, unless we further
subdivide
and have gen:set-query gen:set-constructor gen:set-mconstruct.
   
-Ian
- Original Message -
From: Jay McCarthy jay.mccar...@gmail.com
To: Carl Eastlund c...@ccs.neu.edu
Cc: Racket Developers dev@racket-lang.org
Sent: Wednesday, October 2, 2013 3:23:07 PM GMT -05:00 US/Canada
Eastern
Subject: Re: [racket-dev] Generics updates
   
Regarding a point from RacketCon, I don't like that gen:set
 includes
functions like set-add! and set-remove!. I think that sets with
mutations are subclass of get:set and we should have a separate
gen:mset (or something) interface for mutable versions.
   
I dislike that an obvious implementation of sets, hash tables, are
not
sets to gen:set, because there are operations that cannot be
performed
on them.
   
I think that X implements generic G should imply All functions
 of
G
work on X. But this is not the case with gen:set and hasheq sets,
for
instance.
   
Jay
   
   
On Tue, Jul 23, 2013 at 9:37 AM, Carl Eastlund c...@ccs.neu.edu
wrote:
My work on adding gen:set, and related changes to define-generics
and
gen:dict, is ready for review and (hopefully) to push to the
 master
branch.
The branch moved in the process of cleaning things up, it's now
 at:
   
   
 https://github.com/carl-eastlund/racket/tree/generics-from-scratch
   
(The from scratch just refers to the process of rebuilding the
 git
history, I didn't go out of my way to rewrite anything in the code
base
from
scratch, although in some places a lot of code did move around.)
   
What's new in the branch:
   
- Generics now support a few new options
  - #:fallbacks specifies

Re: [racket-dev] [plt] Push #27511: master branch updated

2013-09-16 Thread Carl Eastlund
Perhaps some macro hackery on the defmodule form to make it into
defmodule-if-exists and only document that the module is typed if it is
actually installed?

Carl Eastlund


On Mon, Sep 16, 2013 at 4:21 PM, Asumu Takikawa as...@ccs.neu.edu wrote:

 On 2013-09-16 16:17:33 -0400, as...@racket-lang.org wrote:
  +@defmodule[math #:no-declare #:link-target? #f]
  +@defmodule[plot/typed #:no-declare #:link-target? #f]

 These two lines cause `raco setup` to complain with a warning about
 undeclared dependencies. It seems silly, though, to have the TR doc
 package force a dependency on `math`. Can I quelch the warning somehow?
 (like a I don't really care if the dependency is missing flag)

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


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


Re: [racket-dev] call-with-limits memory bound isn't actually bounding memory usage

2013-09-09 Thread Carl Eastlund
Does run-analysis have the form (lambda () actually-run-analysis)?
Because if not, that's the problem.

Carl Eastlund

--
WARNING!  Poorly-typed cell phone email precedes.
On Sep 9, 2013 11:55 AM, J. Ian Johnson i...@ccs.neu.edu wrote:

 I'm running my analysis benchmarks in the context of (with-limits (* 30
 60) 2048 run-analysis), and it's been good at killing the process when
 the run should time out, but now I have an instantiation of the framework
 that just gobbles up 15GiB of memory without getting killed. What might be
 going on here?

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


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


Re: [racket-dev] call-with-limits memory bound isn't actually bounding memory usage

2013-09-09 Thread Carl Eastlund
Argh, sorry, I read the docs for the wrong one, sorry for the misleading
response.

Carl Eastlund

--
WARNING!  Poorly-typed cell phone email precedes.
On Sep 9, 2013 12:16 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 I changed it to (call-with-limits (* 30 60) 2048 (lambda ()
 run-analysis)) for a sanity check, which I thought with-limits was just a
 macro for. Same problem. The execution takes at least 20 seconds to get to
 15GiB, so it can't be just that GC isn't running in order for the custodian
 to notice the usage over the limit.
 -Ian
 - Original Message -
 From: Carl Eastlund carl.eastl...@gmail.com
 To: J. Ian Johnson i...@ccs.neu.edu
 Cc: dev dev@racket-lang.org
 Sent: Monday, September 9, 2013 12:05:21 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] call-with-limits memory bound isn't actually
 bounding memory usage



 Does run-analysis have the form (lambda () actually-run-analysis)?
 Because if not, that's the problem.

 Carl Eastlund

 --
 WARNING! Poorly-typed cell phone email precedes.
 On Sep 9, 2013 11:55 AM, J. Ian Johnson  i...@ccs.neu.edu  wrote:


 I'm running my analysis benchmarks in the context of (with-limits (* 30
 60) 2048 run-analysis), and it's been good at killing the process when
 the run should time out, but now I have an instantiation of the framework
 that just gobbles up 15GiB of memory without getting killed. What might be
 going on here?

 Running 5.90.0.9
 -Ian
 _
 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

2013-09-08 Thread Carl Eastlund
On Fri, Sep 6, 2013 at 2:58 PM, Stephen Chang stch...@ccs.neu.edu wrote:

  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?


Are you looking for an equivalent of C's continue statement?  I could
imagine clauses for skipping to the next iteration using the keyword
#:continue or #:next, though I have no idea if the existing loop
architecture would easily accommodate them.  I don't think calling them
#:when or #:unless makes sense outside the for clauses.


   Carl Eastlund
  
  
   On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang stch...@ccs.neu.edu
   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 c...@ccs.neu.edu
 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 mfl...@cs.utah.edu
 
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
 mfl...@cs.utah.edu
 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

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

2013-09-06 Thread 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 stch...@ccs.neu.edu 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 c...@ccs.neu.edu 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 mfl...@cs.utah.edu
 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 mfl...@cs.utah.edu
   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 
 mfl...@cs.utah.edu
wrote:

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

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

2013-09-06 Thread 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 mfl...@cs.utah.edu 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 mfl...@cs.utah.edu
 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 mfl...@cs.utah.edu
   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

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

2013-09-06 Thread Carl Eastlund
On Fri, Sep 6, 2013 at 2:43 PM, Stephen Chang stch...@ccs.neu.edu wrote:

 On Fri, Sep 6, 2013 at 2:36 PM, Carl Eastlund c...@ccs.neu.edu 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 stch...@ccs.neu.edu
 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 c...@ccs.neu.edu 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 mfl...@cs.utah.edu
   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 mfl...@cs.utah.edu
 
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

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

2013-09-06 Thread 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 mfl...@cs.utah.edu 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

2013-09-06 Thread 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 mfl...@cs.utah.edu 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 mfl...@cs.utah.edu
 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

2013-09-06 Thread 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] Output value of program changes depending on whether I pretty-print an opaque struct value

2013-08-28 Thread Carl Eastlund
Is it possible your analysis is depending on the order of graph traversal?
That is, do you ever use in-hash on the hasheq, and if so is it possible
the results of your analysis would change if in-hash produced hash table
entries in a different order?  Same for in-hash-keys or in-hash-values,
obviously.

Carl Eastlund


On Tue, Aug 27, 2013 at 6:58 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 Weird you can't repro.
 I only use hasheq when I know the keys are symbols, or the table is local
 and only used for a graph traversal (where the graph is not changing during
 traversal).
 -Ian
 - Original Message -
 From: Matthew Flatt mfl...@cs.utah.edu
 To: J. Ian Johnson i...@ccs.neu.edu
 Cc: dev dev@racket-lang.org
 Sent: Tuesday, August 27, 2013 6:33:02 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Output value of program changes depending on
 whether I pretty-print an opaque struct value

 I haven't been able to get a different result by changing printing.

 One thing that printing might do, however, is assign `eq?`-based hash
 codes to objects that did not already have them. That assignment, in
 turn, could affect the order in which objects appear later in a hash
 table.

 I hacked Racket to make the internal hash-code generator count down
 instead of up, and I was able to get a different result that way.

 Are you using `eq?`-based hashing at all? Could there be some
 dependency on the order of values within a hash table (or hash set)?

 At Tue, 27 Aug 2013 14:02:50 -0400 (EDT), J. Ian Johnson wrote:
  This is mostly an mflatt-only problem.
 
  My analysis framework is now using a generic dictionary for its abstract
 heap,
  and depending on whether or not I pretty-print this heap before
 continuing on
  analyzing, the result of the analysis changes (sound versus unsound). I
 found
  the problem doing some printf debugging, and when fixed, I tried
 removing the
  print statements. The answer changed. There must be some problem in the
 C code
  somewhere, because this is just bonkers.
 
  (Note: I've had previous bugs where rewriting a (begin (void) e) = e
 caused a
  similar value-changing bug. Updating the compiler to head fixed it at
 that
  point. I'm running yesterday's HEAD now, though.)
 
  https://github.com/dvanhorn/oaam/tree/thocon
 
  See the ;; mflatt: comment in code/kcfa.rkt
 
  To see the problem,
  racket code/run-benchmark.rkt --lcg benchmarks/temp-c/sort2.sch
 
  Thanks,
  -Ian
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev

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


Re: [racket-dev] can a syntax-class inherit attributes?

2013-08-23 Thread Carl Eastlund
You'd have to ask Ryan to be sure, but I think they're pretty stable.  I've
been using them for some time.

Carl Eastlund


On Fri, Aug 23, 2013 at 12:53 PM, Stephen Chang stch...@ccs.neu.edu wrote:

 Ah, thanks. That's exactly what I wanted.

 How stable are these features? Shall I add them to the docs?

 On Fri, Aug 23, 2013 at 12:54 AM, Carl Eastlund c...@ccs.neu.edu wrote:
  Here's how you want to define AorB:
 
  (define-syntax-class AorB #:auto-nested-attributes
(pattern :A)
(pattern :B))
 
  There's two things going on here, both of which I believe are
 undocumented,
  sadly.
 
  One is #:auto-nested-attributes, an option that tells AorB that anything
  bound as an attribute by nested sub-patterns in its clauses should
  automatically become an attribute of AorB.
 
  The other is that empty identifier does not add . to its attribute
 names.
  When you bind a with the attribute X, you get A.X, and when you bind b,
 you
  get b.X, but when you bind the empty identifier, you just get X.
 
  So now you just have X bound in both clauses, and that's automatically
 made
  an attribute of AorB, and it all works like you want.
 
  Carl Eastlund
 
 
  On Fri, Aug 23, 2013 at 12:22 AM, Stephen Chang stch...@ccs.neu.edu
 wrote:
 
  Is there a way for a syntax-class to automatically inherit attributes?
 
  For example, the third class below combines the first two. Is there a
  way to automatically get the attributes from the first two classes in
  the third one (ie, I want to drop the #:attr X #'a.X part in the
  third class)?
 
  #lang racket
  (require syntax/parse)
 
  (define-syntax-class A (pattern (a b) #:attr X #'b))
  (define-syntax-class B (pattern (a b c) #:attr X #'c))
  (define-syntax-class AorB
(pattern a:A #:attr X #'a.X)
(pattern b:B #:attr X #'b.X))
 
  (syntax-parse #'(list 1) [ab:AorB (attribute ab.X)])
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
 


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


Re: [racket-dev] Lists aren't sets, but have set-like operations

2013-08-22 Thread Carl Eastlund
Set-union never worked for even different hash set representations.  Even
before I touched the code, the union of an eq set and an eqv set, for
instance, caused a runtime error.

Generics do not have multiple dispatch.  That's not a mechanism we have
right now.  And fallbacks are for when there's no method implemented for
a given receiver value, they're not particularly related to a question of
are these things the same type.

I chose to keep the semantics that union and operations like it only work
with the same representation.  Partly because that's how things already
were, and partly to set the precedent that generics authors don't have to
write two versions of every method.  Perhaps this wasn't the best idiom,
but it's what I wrote.  Perhaps there's a better idiom for fallbacks that
makes this work more cleanly.  Anyway, right now, generic sets are designed
so you can use any one representation, but they don't combine
representations.

Carl Eastlund


On Thu, Aug 22, 2013 at 9:03 AM, J. Ian Johnson i...@ccs.neu.edu wrote:

 No, it doesn't seem to be using the fallback in this case.

 ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl
 Welcome to Racket v5.90.0.8.
 - (set-union '() (set))
 ; in-list: contract violation
 ;   expected: list?
 ;   given: (set)
 ; [,bt for context]
 -

 -Ian
 - Original Message -
 From: Sam Tobin-Hochstadt sa...@cs.indiana.edu
 To: J. Ian Johnson i...@ccs.neu.edu, Carl Eastlund c...@ccs.neu.edu
 Cc: dev@racket-lang.org, Matthew Flatt mfl...@cs.utah.edu
 Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations

 Wait, `set-union` of two different set representations doesn't work?

 Sam

 On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson i...@ccs.neu.edu wrote:
  You misunderstand. I used set-union, but single dispatch saw '() and
 used list-union for the '() (set) combination.
  -Ian
  - Original Message -
  From: Sam Tobin-Hochstadt sa...@cs.indiana.edu
  To: J. Ian Johnson i...@ccs.neu.edu
  Cc: dev@racket-lang.org, Matthew Flatt mfl...@cs.utah.edu
  Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada Eastern
  Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations
 
 
 
  But 'list-union' is not a generic operation so it isn't surprising that
 this didn't work. To do this generically, you'd need to use 'set-union'.
 
  Sam
  On Aug 22, 2013 7:59 AM, J. Ian Johnson  i...@ccs.neu.edu  wrote:
 
 
  The problem manifested itself when I got an exception that in-list can't
 be called on (set), which really confused me. (set? '()) answered true, so
 it tried to do (list-union '() (set)), which failed.
  Generic sets as they are don't work generically. Some action should be
 taken. Either set? means what it once did, or we do some awfully slow
 multiple dispatch for set operations. My bias shows.
  -Ian
  - Original Message -
  From: Matthew Flatt  mfl...@cs.utah.edu 
  To: Carl Eastlund  c...@ccs.neu.edu 
  Cc: J. Ian Johnson  i...@ccs.neu.edu , dev  dev@racket-lang.org 
  Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada Eastern
  Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations
 
  How much should we prioritize backward compatibility in this case?
 
  One possibility is to make `set?' mean `hash-set?', and add
  `generic-set?' in place of the current `set?'. That's uglier,
  obviously, but it would be better if we want to prioritize backward
  compatibility.
 
  At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote:
  Ah, yes. The set? predicate no longer distinguishes a representation.
  There are several predicates for the original set type, now called hash
  sets: set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and
  set-weak?. I didn't add the basic hash-set?, but perhaps I should.
 It's
  a weird name, since hash-set and hash-set! are already existing,
  unrelated functions.
 
  Carl Eastlund
 
 
  On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson  i...@ccs.neu.edu 
 wrote:
 
   Okay, I can abide. However, that doesn't really get at my
 frustration. I'm
   using the set constructor, that appears to now be an
 immutable-custom-set
   with make-immutable-hash as its make-table. So what I'm looking for
 is not
   set?, but set-immutable?, as it's a distinct (family of) struct types
 that
   won't clash with the primitive data that I'm otherwise using.
   -Ian
   - Original Message -
   From: Carl Eastlund  c...@ccs.neu.edu 
   To: J. Ian Johnson  i...@ccs.neu.edu 
   Cc: dev  dev@racket-lang.org 
   Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada
 Eastern
   Subject: Re: [racket-dev] Lists aren't sets, but have set-like
 operations
  
  
   Ian, sets are now a generic datatype, like dictionaries. Association
 lists
   are dictionaries, and lists are now sets. They're also streams and
   sequences. They're not just set-like.
  
  
  
   Carl Eastlund

Re: [racket-dev] Lists aren't sets, but have set-like operations

2013-08-22 Thread Carl Eastlund
The implementation of set-union for hash sets would be unnecessarily slow
if that's how I wrote it.  It's faster to extract the hash tables and
operate directly on those.  It's even faster still to find the largest
immutable hash table in the argument list and start from that.  On top of
that, the operation is specified, since before my changes, to go through
the arguments and reject any hash sets that use a different notion of
equality, so that the output of set-union has a meaningful semantics.  For
an arbitrary other set representation, I don't necessarily know what the
notion of equality is.  So currently, I just reject all of them.

Carl Eastlund


On Thu, Aug 22, 2013 at 1:52 PM, Jay McCarthy jay.mccar...@gmail.comwrote:

 I find this an unsatisfying consequence of the implementation and not
 necessary. For instance, you could implement set-union purely
 generically as:

 (define (set-union a b)
  (for/fold ([a a]) ([e (in-set b)]) (set-add a e)))

 and then it would work for everything. Right?

 Jay

 On Thu, Aug 22, 2013 at 10:14 AM, Carl Eastlund c...@ccs.neu.edu wrote:
  Set-union never worked for even different hash set representations.  Even
  before I touched the code, the union of an eq set and an eqv set, for
  instance, caused a runtime error.
 
  Generics do not have multiple dispatch.  That's not a mechanism we have
  right now.  And fallbacks are for when there's no method implemented
 for a
  given receiver value, they're not particularly related to a question of
 are
  these things the same type.
 
  I chose to keep the semantics that union and operations like it only work
  with the same representation.  Partly because that's how things already
  were, and partly to set the precedent that generics authors don't have to
  write two versions of every method.  Perhaps this wasn't the best idiom,
 but
  it's what I wrote.  Perhaps there's a better idiom for fallbacks that
 makes
  this work more cleanly.  Anyway, right now, generic sets are designed so
 you
  can use any one representation, but they don't combine representations.
 
  Carl Eastlund
 
 
  On Thu, Aug 22, 2013 at 9:03 AM, J. Ian Johnson i...@ccs.neu.edu
 wrote:
 
  No, it doesn't seem to be using the fallback in this case.
 
  ianj@sampson:~/racket/racket/bin$ ./racket -il xrepl
  Welcome to Racket v5.90.0.8.
  - (set-union '() (set))
  ; in-list: contract violation
  ;   expected: list?
  ;   given: (set)
  ; [,bt for context]
  -
 
  -Ian
  - Original Message -
  From: Sam Tobin-Hochstadt sa...@cs.indiana.edu
  To: J. Ian Johnson i...@ccs.neu.edu, Carl Eastlund 
 c...@ccs.neu.edu
  Cc: dev@racket-lang.org, Matthew Flatt mfl...@cs.utah.edu
  Sent: Thursday, August 22, 2013 8:51:30 AM GMT -05:00 US/Canada Eastern
  Subject: Re: [racket-dev] Lists aren't sets, but have set-like
 operations
 
  Wait, `set-union` of two different set representations doesn't work?
 
  Sam
 
  On Thu, Aug 22, 2013 at 8:07 AM, J. Ian Johnson i...@ccs.neu.edu
 wrote:
   You misunderstand. I used set-union, but single dispatch saw '() and
   used list-union for the '() (set) combination.
   -Ian
   - Original Message -
   From: Sam Tobin-Hochstadt sa...@cs.indiana.edu
   To: J. Ian Johnson i...@ccs.neu.edu
   Cc: dev@racket-lang.org, Matthew Flatt mfl...@cs.utah.edu
   Sent: Thursday, August 22, 2013 8:02:50 AM GMT -05:00 US/Canada
 Eastern
   Subject: Re: [racket-dev] Lists aren't sets, but have set-like
   operations
  
  
  
   But 'list-union' is not a generic operation so it isn't surprising
 that
   this didn't work. To do this generically, you'd need to use
 'set-union'.
  
   Sam
   On Aug 22, 2013 7:59 AM, J. Ian Johnson  i...@ccs.neu.edu  wrote:
  
  
   The problem manifested itself when I got an exception that in-list
 can't
   be called on (set), which really confused me. (set? '()) answered
 true, so
   it tried to do (list-union '() (set)), which failed.
   Generic sets as they are don't work generically. Some action should be
   taken. Either set? means what it once did, or we do some awfully slow
   multiple dispatch for set operations. My bias shows.
   -Ian
   - Original Message -
   From: Matthew Flatt  mfl...@cs.utah.edu 
   To: Carl Eastlund  c...@ccs.neu.edu 
   Cc: J. Ian Johnson  i...@ccs.neu.edu , dev 
 dev@racket-lang.org 
   Sent: Thursday, August 22, 2013 7:22:25 AM GMT -05:00 US/Canada
 Eastern
   Subject: Re: [racket-dev] Lists aren't sets, but have set-like
   operations
  
   How much should we prioritize backward compatibility in this case?
  
   One possibility is to make `set?' mean `hash-set?', and add
   `generic-set?' in place of the current `set?'. That's uglier,
   obviously, but it would be better if we want to prioritize backward
   compatibility.
  
   At Wed, 21 Aug 2013 19:14:06 -0400, Carl Eastlund wrote:
   Ah, yes. The set? predicate no longer distinguishes a representation.
   There are several predicates for the original set type, now called
   hash
   sets: set-eq?, set-eqv

Re: [racket-dev] can a syntax-class inherit attributes?

2013-08-22 Thread Carl Eastlund
Here's how you want to define AorB:

(define-syntax-class AorB #:auto-nested-attributes
  (pattern :A)
  (pattern :B))

There's two things going on here, both of which I believe are undocumented,
sadly.

One is #:auto-nested-attributes, an option that tells AorB that anything
bound as an attribute by nested sub-patterns in its clauses should
automatically become an attribute of AorB.

The other is that empty identifier does not add . to its attribute
names.  When you bind a with the attribute X, you get A.X, and when you
bind b, you get b.X, but when you bind the empty identifier, you just get X.

So now you just have X bound in both clauses, and that's automatically made
an attribute of AorB, and it all works like you want.

Carl Eastlund


On Fri, Aug 23, 2013 at 12:22 AM, Stephen Chang stch...@ccs.neu.edu wrote:

 Is there a way for a syntax-class to automatically inherit attributes?

 For example, the third class below combines the first two. Is there a
 way to automatically get the attributes from the first two classes in
 the third one (ie, I want to drop the #:attr X #'a.X part in the
 third class)?

 #lang racket
 (require syntax/parse)

 (define-syntax-class A (pattern (a b) #:attr X #'b))
 (define-syntax-class B (pattern (a b c) #:attr X #'c))
 (define-syntax-class AorB
   (pattern a:A #:attr X #'a.X)
   (pattern b:B #:attr X #'b.X))

 (syntax-parse #'(list 1) [ab:AorB (attribute ab.X)])
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev


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


Re: [racket-dev] Lists aren't sets, but have set-like operations

2013-08-21 Thread Carl Eastlund
Ian, sets are now a generic datatype, like dictionaries.  Association lists
are dictionaries, and lists are now sets.  They're also streams and
sequences.  They're not just set-like.

Carl Eastlund


On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 I just wasted about 2 hours tracking down a bug that ended up being due to
 (set? '()) now evaluating to #t. I have no problems with set-union,
 intersection, etc. being defined for lists, but to treat lists as sets
 always is perverse to me. The contracts for set operations should use
 set-like? for (or/c set? list?) and keep the two constructions separate.

 This conflation is almost as bad as treating empty list as false.

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


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


Re: [racket-dev] Lists aren't sets, but have set-like operations

2013-08-21 Thread Carl Eastlund
Ah, yes.  The set? predicate no longer distinguishes a representation.
There are several predicates for the original set type, now called hash
sets: set-eq?, set-eqv?, set-equal?, set-mutable?, set-immtuable?, and
set-weak?.  I didn't add the basic hash-set?, but perhaps I should.  It's
a weird name, since hash-set and hash-set! are already existing,
unrelated functions.

Carl Eastlund


On Wed, Aug 21, 2013 at 7:08 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 Okay, I can abide. However, that doesn't really get at my frustration. I'm
 using the set constructor, that appears to now be an immutable-custom-set
 with make-immutable-hash as its make-table. So what I'm looking for is not
 set?, but set-immutable?, as it's a distinct (family of) struct types that
 won't clash with the primitive data that I'm otherwise using.
 -Ian
 - Original Message -
 From: Carl Eastlund c...@ccs.neu.edu
 To: J. Ian Johnson i...@ccs.neu.edu
 Cc: dev dev@racket-lang.org
 Sent: Wednesday, August 21, 2013 6:58:56 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Lists aren't sets, but have set-like operations


 Ian, sets are now a generic datatype, like dictionaries. Association lists
 are dictionaries, and lists are now sets. They're also streams and
 sequences. They're not just set-like.



 Carl Eastlund


 On Wed, Aug 21, 2013 at 6:56 PM, J. Ian Johnson  i...@ccs.neu.edu 
 wrote:


 I just wasted about 2 hours tracking down a bug that ended up being due to
 (set? '()) now evaluating to #t. I have no problems with set-union,
 intersection, etc. being defined for lists, but to treat lists as sets
 always is perverse to me. The contracts for set operations should use
 set-like? for (or/c set? list?) and keep the two constructions separate.

 This conflation is almost as bad as treating empty list as false.

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




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


Re: [racket-dev] Generics scoping issues

2013-08-16 Thread Carl Eastlund
Problem 1 -- you have to use define/generic if you want to use the generic
version of something in the context of a set of specific method
implementations.  That's by design.

Problem 2 -- what error message or unexpected behavior are you getting?
That should work, it sounds like a bug in define/generic if it's not
working.

Carl Eastlund


On Fri, Aug 16, 2013 at 4:36 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 I'm starting to use generics, and me being myself, I wrote some macros to
 make writing method definitions easier.
 But, I'm seeing that #:methods seems to rebind method identifiers in a way
 that hygiene interferes with.

 I would expect to be allowed to do the following two things (problems
 annotated):

 (struct exp (label fvs-box)) ;; parent struct for all expressions
 (define-generics binds-variables
   [free-box binds-variables]
   [free binds-variables #:bound [bound]]
   #:fallbacks [(define (free e #:bound [bound ∅]) ∅)
(define free-box exp-fvs-box)]
   #:fast-defaults ([(compose unbox free-box)
 (define (free e #:bound bound) (unbox (free-box
 e)))])) ;; problem 1: free-box not in scope

 (define-syntax-rule (def-free e gfree bound struct [(pats ...) rhss ...])
   (begin
 (define/generic gfree free) ;; problem 2: since #:methods rebinds
 free, this is not in the scope one would expect with its definition in the
 define-generics form.
 (define (free e #:bound [bound ∅])
  (match e [(struct _ fvs-box pats ...)
(set-box! fvs-box
  (let () rhss ...))]

 (struct var exp (name) #:transparent
 #:methods gen:binds-variables
 [(def-free e gfree bound var [(x) (if (x . ∈ . bound) ∅ (set
 x))])])

 I have workarounds thanks to stamourv, but they're unpleasant:
 Problem 1: define free in fast-defaults as an eta-expansion of a
 definition outside the define-generics form that does what you want.
 Problem 2: add free as a parameter to def-free, and pass free in at all
 uses of def-free.

 The first problem seems like more of a programming error than the use of
 the wrong tool.
 The second problem seems like generic method identifiers should be
 syntax-parameters, if they indeed need to be rebound in the rhs of the
 #:methods argument.

 Are these expectations unreasonable/against the design decisions for
 generics?
 Thanks,
 -Ian

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

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


Re: [racket-dev] Generics scoping issues

2013-08-16 Thread Carl Eastlund
The method names are always going to be in the context of the generic
interface name.  There's nowhere else they can come from.

Carl Eastlund


On Fri, Aug 16, 2013 at 5:39 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 WRT the struct abstraction, using syntax-local-introduce on
 #'gen:binds-variables seemed to do the trick, oddly.
 -Ian
 - Original Message -
 From: Carl Eastlund c...@ccs.neu.edu
 To: J. Ian Johnson i...@ccs.neu.edu
 Cc: dev dev@racket-lang.org
 Sent: Friday, August 16, 2013 5:23:33 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Generics scoping issues


 Okay, let me dig into this. The expansion of define/generic is an odd
 thing in the way it treats the method names; I'm not at all sure I've
 gotten it right, or that it's clear what right should even be. I'll get
 back to you shortly.



 Carl Eastlund


 On Fri, Aug 16, 2013 at 5:17 PM, J. Ian Johnson  i...@ccs.neu.edu 
 wrote:


 Re: problem 1 - ah yes I see.
 Problem 2:
 In the body of def-free:

 generic-problems.rkt:16:26: define/generic: free is not a method of
 generic interfaces gen:binds-variables
 at: free
 in: (define/generic gfree free)

 This compiles if I additionally supply def-free with free, but it doesn't
 run:
 free-box: undefined;
 cannot reference an identifier before its definition
 in module: /home/ianj/projects/oaam/code/generic-problems.rkt
 context...:
 /home/ianj/projects/oaam/code/generic-problems.rkt: [running body]

 Furthermore, if I abstract over the struct form so that #:methods
 gen:binds-variables is part of the macro expansion, even passing free to
 def-free won't work anymore:

 (define-syntax-rule (astruct name (fields ...) (methods ...))
 (struct name exp (fields ...) #:transparent #:methods gen:binds-variables
 [methods ...]))

 (astruct avar (name)
 [(def-free e gfree free bound avar [(x) (if (x . ∈ . bound) ∅ (set x))])])

 generic-problems.rkt:31:27: define/generic: free is not a method of
 generic interfaces gen:binds-variables
 at: free
 in: (define/generic gfree free)




 - Original Message -
 From: Carl Eastlund  c...@ccs.neu.edu 
 To: J. Ian Johnson  i...@ccs.neu.edu 
 Cc: dev  dev@racket-lang.org 
 Sent: Friday, August 16, 2013 4:50:53 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Generics scoping issues



 Problem 1 -- you have to use define/generic if you want to use the generic
 version of something in the context of a set of specific method
 implementations. That's by design.

 Problem 2 -- what error message or unexpected behavior are you getting?
 That should work, it sounds like a bug in define/generic if it's not
 working.



 Carl Eastlund


 On Fri, Aug 16, 2013 at 4:36 PM, J. Ian Johnson  i...@ccs.neu.edu 
 wrote:


 I'm starting to use generics, and me being myself, I wrote some macros to
 make writing method definitions easier.
 But, I'm seeing that #:methods seems to rebind method identifiers in a way
 that hygiene interferes with.

 I would expect to be allowed to do the following two things (problems
 annotated):

 (struct exp (label fvs-box)) ;; parent struct for all expressions
 (define-generics binds-variables
 [free-box binds-variables]
 [free binds-variables #:bound [bound]]
 #:fallbacks [(define (free e #:bound [bound ∅]) ∅)
 (define free-box exp-fvs-box)]
 #:fast-defaults ([(compose unbox free-box)
 (define (free e #:bound bound) (unbox (free-box e)))])) ;; problem 1:
 free-box not in scope

 (define-syntax-rule (def-free e gfree bound struct [(pats ...) rhss ...])
 (begin
 (define/generic gfree free) ;; problem 2: since #:methods rebinds free,
 this is not in the scope one would expect with its definition in the
 define-generics form.
 (define (free e #:bound [bound ∅])
 (match e [(struct _ fvs-box pats ...)
 (set-box! fvs-box
 (let () rhss ...))]

 (struct var exp (name) #:transparent
 #:methods gen:binds-variables
 [(def-free e gfree bound var [(x) (if (x . ∈ . bound) ∅ (set x))])])

 I have workarounds thanks to stamourv, but they're unpleasant:
 Problem 1: define free in fast-defaults as an eta-expansion of a
 definition outside the define-generics form that does what you want.
 Problem 2: add free as a parameter to def-free, and pass free in at all
 uses of def-free.

 The first problem seems like more of a programming error than the use of
 the wrong tool.
 The second problem seems like generic method identifiers should be
 syntax-parameters, if they indeed need to be rebound in the rhs of the
 #:methods argument.

 Are these expectations unreasonable/against the design decisions for
 generics?
 Thanks,
 -Ian

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





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


Re: [racket-dev] Generics scoping issues

2013-08-16 Thread Carl Eastlund
The method name you give to define/generic is interpreted in the context of
the generic interface name you provide.  So if you supply the name free
inside a macro, that's the wrong context.  That error goes away, as you
found, if you pass free as an argument to def-free.

After that, you get the error free-box: undefined because the
#:fast-defaults predicate is lifted to a definition that comes before the
definition of the free-box method.  I'll fix that by reordering the
definitions; meanwhile you can fix that by just eta-expanding your use of
compose.

Carl Eastlund


On Fri, Aug 16, 2013 at 5:41 PM, Carl Eastlund c...@ccs.neu.edu wrote:

 The method names are always going to be in the context of the generic
 interface name.  There's nowhere else they can come from.

 Carl Eastlund


 On Fri, Aug 16, 2013 at 5:39 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 WRT the struct abstraction, using syntax-local-introduce on
 #'gen:binds-variables seemed to do the trick, oddly.
 -Ian
 - Original Message -
 From: Carl Eastlund c...@ccs.neu.edu
 To: J. Ian Johnson i...@ccs.neu.edu
 Cc: dev dev@racket-lang.org
 Sent: Friday, August 16, 2013 5:23:33 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Generics scoping issues


 Okay, let me dig into this. The expansion of define/generic is an odd
 thing in the way it treats the method names; I'm not at all sure I've
 gotten it right, or that it's clear what right should even be. I'll get
 back to you shortly.



 Carl Eastlund


 On Fri, Aug 16, 2013 at 5:17 PM, J. Ian Johnson  i...@ccs.neu.edu 
 wrote:


 Re: problem 1 - ah yes I see.
 Problem 2:
 In the body of def-free:

 generic-problems.rkt:16:26: define/generic: free is not a method of
 generic interfaces gen:binds-variables
 at: free
 in: (define/generic gfree free)

 This compiles if I additionally supply def-free with free, but it doesn't
 run:
 free-box: undefined;
 cannot reference an identifier before its definition
 in module: /home/ianj/projects/oaam/code/generic-problems.rkt
 context...:
 /home/ianj/projects/oaam/code/generic-problems.rkt: [running body]

 Furthermore, if I abstract over the struct form so that #:methods
 gen:binds-variables is part of the macro expansion, even passing free to
 def-free won't work anymore:

 (define-syntax-rule (astruct name (fields ...) (methods ...))
 (struct name exp (fields ...) #:transparent #:methods gen:binds-variables
 [methods ...]))

 (astruct avar (name)
 [(def-free e gfree free bound avar [(x) (if (x . ∈ . bound) ∅ (set x))])])

 generic-problems.rkt:31:27: define/generic: free is not a method of
 generic interfaces gen:binds-variables
 at: free
 in: (define/generic gfree free)




 - Original Message -
 From: Carl Eastlund  c...@ccs.neu.edu 
 To: J. Ian Johnson  i...@ccs.neu.edu 
 Cc: dev  dev@racket-lang.org 
 Sent: Friday, August 16, 2013 4:50:53 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Generics scoping issues



 Problem 1 -- you have to use define/generic if you want to use the
 generic version of something in the context of a set of specific method
 implementations. That's by design.

 Problem 2 -- what error message or unexpected behavior are you getting?
 That should work, it sounds like a bug in define/generic if it's not
 working.



 Carl Eastlund


 On Fri, Aug 16, 2013 at 4:36 PM, J. Ian Johnson  i...@ccs.neu.edu 
 wrote:


 I'm starting to use generics, and me being myself, I wrote some macros to
 make writing method definitions easier.
 But, I'm seeing that #:methods seems to rebind method identifiers in a
 way that hygiene interferes with.

 I would expect to be allowed to do the following two things (problems
 annotated):

 (struct exp (label fvs-box)) ;; parent struct for all expressions
 (define-generics binds-variables
 [free-box binds-variables]
 [free binds-variables #:bound [bound]]
 #:fallbacks [(define (free e #:bound [bound ∅]) ∅)
 (define free-box exp-fvs-box)]
 #:fast-defaults ([(compose unbox free-box)
 (define (free e #:bound bound) (unbox (free-box e)))])) ;; problem 1:
 free-box not in scope

 (define-syntax-rule (def-free e gfree bound struct [(pats ...) rhss ...])
 (begin
 (define/generic gfree free) ;; problem 2: since #:methods rebinds free,
 this is not in the scope one would expect with its definition in the
 define-generics form.
 (define (free e #:bound [bound ∅])
 (match e [(struct _ fvs-box pats ...)
 (set-box! fvs-box
 (let () rhss ...))]

 (struct var exp (name) #:transparent
 #:methods gen:binds-variables
 [(def-free e gfree bound var [(x) (if (x . ∈ . bound) ∅ (set x))])])

 I have workarounds thanks to stamourv, but they're unpleasant:
 Problem 1: define free in fast-defaults as an eta-expansion of a
 definition outside the define-generics form that does what you want.
 Problem 2: add free as a parameter to def-free, and pass free in at all
 uses of def-free.

 The first problem seems like more of a programming error than the use of
 the wrong tool.
 The second

Re: [racket-dev] Generics scoping issues

2013-08-16 Thread Carl Eastlund
Mind you, I don't think this example -- using a method in a #:fast-defaults
predicate -- can work.  The implementation of free-box will have to check
the predicate in order to perform generic dispatch, and the predicate has
to call free-box, so it will diverge.

Carl Eastlund


On Fri, Aug 16, 2013 at 6:51 PM, Carl Eastlund c...@ccs.neu.edu wrote:

 The method name you give to define/generic is interpreted in the context
 of the generic interface name you provide.  So if you supply the name
 free inside a macro, that's the wrong context.  That error goes away, as
 you found, if you pass free as an argument to def-free.

 After that, you get the error free-box: undefined because the
 #:fast-defaults predicate is lifted to a definition that comes before the
 definition of the free-box method.  I'll fix that by reordering the
 definitions; meanwhile you can fix that by just eta-expanding your use of
 compose.

 Carl Eastlund


 On Fri, Aug 16, 2013 at 5:41 PM, Carl Eastlund c...@ccs.neu.edu wrote:

 The method names are always going to be in the context of the generic
 interface name.  There's nowhere else they can come from.

 Carl Eastlund


 On Fri, Aug 16, 2013 at 5:39 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 WRT the struct abstraction, using syntax-local-introduce on
 #'gen:binds-variables seemed to do the trick, oddly.
 -Ian
 - Original Message -
 From: Carl Eastlund c...@ccs.neu.edu
 To: J. Ian Johnson i...@ccs.neu.edu
 Cc: dev dev@racket-lang.org
 Sent: Friday, August 16, 2013 5:23:33 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Generics scoping issues


 Okay, let me dig into this. The expansion of define/generic is an odd
 thing in the way it treats the method names; I'm not at all sure I've
 gotten it right, or that it's clear what right should even be. I'll get
 back to you shortly.



 Carl Eastlund


 On Fri, Aug 16, 2013 at 5:17 PM, J. Ian Johnson  i...@ccs.neu.edu 
 wrote:


 Re: problem 1 - ah yes I see.
 Problem 2:
 In the body of def-free:

 generic-problems.rkt:16:26: define/generic: free is not a method of
 generic interfaces gen:binds-variables
 at: free
 in: (define/generic gfree free)

 This compiles if I additionally supply def-free with free, but it
 doesn't run:
 free-box: undefined;
 cannot reference an identifier before its definition
 in module: /home/ianj/projects/oaam/code/generic-problems.rkt
 context...:
 /home/ianj/projects/oaam/code/generic-problems.rkt: [running body]

 Furthermore, if I abstract over the struct form so that #:methods
 gen:binds-variables is part of the macro expansion, even passing free to
 def-free won't work anymore:

 (define-syntax-rule (astruct name (fields ...) (methods ...))
 (struct name exp (fields ...) #:transparent #:methods
 gen:binds-variables [methods ...]))

 (astruct avar (name)
 [(def-free e gfree free bound avar [(x) (if (x . ∈ . bound) ∅ (set
 x))])])

 generic-problems.rkt:31:27: define/generic: free is not a method of
 generic interfaces gen:binds-variables
 at: free
 in: (define/generic gfree free)




 - Original Message -
 From: Carl Eastlund  c...@ccs.neu.edu 
 To: J. Ian Johnson  i...@ccs.neu.edu 
 Cc: dev  dev@racket-lang.org 
 Sent: Friday, August 16, 2013 4:50:53 PM GMT -05:00 US/Canada Eastern
 Subject: Re: [racket-dev] Generics scoping issues



 Problem 1 -- you have to use define/generic if you want to use the
 generic version of something in the context of a set of specific method
 implementations. That's by design.

 Problem 2 -- what error message or unexpected behavior are you getting?
 That should work, it sounds like a bug in define/generic if it's not
 working.



 Carl Eastlund


 On Fri, Aug 16, 2013 at 4:36 PM, J. Ian Johnson  i...@ccs.neu.edu 
 wrote:


 I'm starting to use generics, and me being myself, I wrote some macros
 to make writing method definitions easier.
 But, I'm seeing that #:methods seems to rebind method identifiers in a
 way that hygiene interferes with.

 I would expect to be allowed to do the following two things (problems
 annotated):

 (struct exp (label fvs-box)) ;; parent struct for all expressions
 (define-generics binds-variables
 [free-box binds-variables]
 [free binds-variables #:bound [bound]]
 #:fallbacks [(define (free e #:bound [bound ∅]) ∅)
 (define free-box exp-fvs-box)]
 #:fast-defaults ([(compose unbox free-box)
 (define (free e #:bound bound) (unbox (free-box e)))])) ;; problem 1:
 free-box not in scope

 (define-syntax-rule (def-free e gfree bound struct [(pats ...) rhss ...])
 (begin
 (define/generic gfree free) ;; problem 2: since #:methods rebinds free,
 this is not in the scope one would expect with its definition in the
 define-generics form.
 (define (free e #:bound [bound ∅])
 (match e [(struct _ fvs-box pats ...)
 (set-box! fvs-box
 (let () rhss ...))]

 (struct var exp (name) #:transparent
 #:methods gen:binds-variables
 [(def-free e gfree bound var [(x) (if (x . ∈ . bound) ∅ (set x))])])

 I have workarounds thanks to stamourv

Re: [racket-dev] Generics updates

2013-08-02 Thread Carl Eastlund
On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang stch...@ccs.neu.edu wrote:

  With that in mind, I think it would make sense to move `set-first' and
  `set-empty?' to the primitive set (making it clear that they are
  optional, and can be derived from `set-stream' if need be). With those
  two in the primitive set, anything that implements all the primitives
  should get all the derived for free, right?

 Oh yeah, I like that better than moving set-stream to primitives
 since they are more standard set operations.


So the proposal for primitive methods is to pick one canonical set of
methods from which all the others can be derived?  I'm fairly sure there's
more than one such set, and I'm not sure there's one choice that's clearly
better than the others. I can understand the benefits of documenting a
suggested set, but given that it is an arbitrary and pragmatic
distinction, I'm not sure I'd want to set them off in a section any more.
I'd just make a list in the gen:set description or something.

Carl, I dont see how guaranteeing some fallback implementations
 affects allowing more efficient versions. I think most programmers
 understand that the default implementation is probably not very
 efficient.


Yes, but a default implementation doesn't have to be inefficient.  Right
now the fallback implementation of set=? and proper-subset? will be
efficient if the implementation of subset? is efficient.  Your proposal to
make fallbacks depend only on primitive methods would prevent that.  I
don't understand why we'd want to prevent intelligent fallbacks like I've
made the effort to write, just to draw a line in the sand.

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


Re: [racket-dev] Generics updates

2013-08-02 Thread Carl Eastlund
Yes, this is an issue.  I kind of vaguely hint at it in the documentation,
and didn't get around to making it an explicit point -- I use the phrase
implements for things that have to be directly implemented, and
supports for sort of transitive implements.  I use in-set and things
like it in some of the fallbacks because the dependencies for set-stream
are somewhat complex, and I didn't want to repeat the logic in each and
every case; I wanted to just call set-stream.  At some point I tried to
make an indirect helper that did dependency checking and reported errors in
terms of the primary method being called, but it got a bit cumbersome.  I
probably should have seen through the better code and docs, but I sort of
hit a point of I need to just push this and see how it goes.

So, for documenting this, off the top of my head I'd define tech terms
implemented method and supported method in the documentation for
define-generics, and refer to them as necessary in methods for gen:set and
so on.  That way, saying that, for instance, set-count is a supported
method whenever set-stream is a supported method, allows the documentation
to imply all the direct dependencies of set-stream on things that need to
be implemented methods, without having to restate them all.

For the implementation, what we have would fit the docs, and it might also
be possible to slightly improve the error messages with some refactoring.

Carl Eastlund


On Fri, Aug 2, 2013 at 3:43 PM, Stephen Chang stch...@ccs.neu.edu wrote:

 Actually, I am realizing that every derived method depends on
 set-stream, even the ones that don't document it (ie set-union,
 set-union!, set-intersect, set-intersect!, etc), since they use
 in-set.

 I was in the process of creating a patch for the docs to add the
 missing dependencies but I ran into an issue that I think warrants
 discussion.

 When the docs specifies dependencies for derived methods, there are
 actually two kinds that are being conflated.

 *** The first kind of dependency is stricter and requires the
 programmer to explicitly implement the required methods, and fallbacks
 do not count. In the code, this dependency is enforced with a call to
 the #:defined-predicated supplied to define-generics.

 Example:

 set-copy says it depends on set-clear and set-add!.

 Below is a set implementation that implements all the primitive
 methods plus set-stream. There exist set-clear and set-add! functions
 but set-clear is a fallback so set-copy wont work. Only if I
 explicitly implement set-clear will I get set-copy.

 (struct lstset (lst)
   #:transparent
   #:methods gen:set
   [(define (set-member? s x) (match s [(lstset lst) (member x lst)]))
(define (set-add s x)
  (match s
[(lstset lst)
 (lstset (cons x (filter (λ (y) (not (equal? y x))) lst)))]))
(define (set-remove s x) (match s [(lstset lst) (lstset (remove x
 lst))]))
(define (set-add! s x) (void))
(define (set-remove! s x) (void))
(define (set-stream s) (lstset-lst s))])

  (set-add (lstset '(1 2)) 4)
 (lstset '(4 1 2))
  (set-clear (lstset '(1 2)))
 (lstset '())
  (set-copy (lstset '(1 2 3)))
 . . set-copy: not implemented for (lstset '(1 2 3))



 *** The second kind of dependency is looser and allows fallbacks. For
 example set-count requires set-stream, but if I implement in-set,
 that is good enough.


 I guess my question is, is this a docs issue, or should the code have
 more calls to set-implements?



 On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang stch...@ccs.neu.edu wrote:
  With that in mind, I think it would make sense to move `set-first' and
  `set-empty?' to the primitive set (making it clear that they are
  optional, and can be derived from `set-stream' if need be). With those
  two in the primitive set, anything that implements all the primitives
  should get all the derived for free, right?
 
  Oh yeah, I like that better than moving set-stream to primitives
  since they are more standard set operations.
 
  Carl, I dont see how guaranteeing some fallback implementations
  affects allowing more efficient versions. I think most programmers
  understand that the default implementation is probably not very
  efficient.
 
 
 
 
 
 
 
  Vincent


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


Re: [racket-dev] Generics updates

2013-08-01 Thread Carl Eastlund
Hmm.  Well, partially, I wasn't sure how to document the methods, because
the relationships are complex, and because we don't have existing
terminology or documentation patterns for this.  I'm open to other
suggestions, and especially (though not exclusively) to patches.  For the
other part, I either should have made it as you say -- implement the
primitive ones and you get the others -- or else I should have clearly
documented the relationship somewhere.  I can't remember, now, if I thought
I had made the primitive ones sufficient, or if I knew there were others
you needed to implement, or if I just forgot to think that whole thing
through.

Do you have examples of which ones don't come for free with the primitive
methods?

Carl Eastlund


On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang stch...@ccs.neu.edu wrote:

 Just played a bit with gen:set. It looks great and in particular the
 fallback implementations are very convenient.

 One comment: the distinction between primitive methods and derived
 methods confused me somewhat. Can you explain the reasoning for
 determining which is which?

 For example, when I first read the docs, I thought that if I
 implemented the primitives, I would get the derived, but that's not
 the case since some of the derived methods depend on each other.
 Reading the docs more thoroughly, it sort of seems like there's an
 implicit separation along the lines of iterability, ie, derived sets
 are iterable since many of the derived methods require set-stream,
 but that's not exactly right either.


 On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund c...@ccs.neu.edu wrote:
  After some fixes, mostly to contracts and documentation, I've pushed the
 new
  generics and set features to the master branch.
 
  Carl Eastlund
 
 
  On Tue, Jul 23, 2013 at 11:37 AM, Carl Eastlund c...@ccs.neu.edu wrote:
 
  My work on adding gen:set, and related changes to define-generics and
  gen:dict, is ready for review and (hopefully) to push to the master
 branch.
  The branch moved in the process of cleaning things up, it's now at:
 
https://github.com/carl-eastlund/racket/tree/generics-from-scratch
 
  (The from scratch just refers to the process of rebuilding the git
  history, I didn't go out of my way to rewrite anything in the code base
 from
  scratch, although in some places a lot of code did move around.)
 
  What's new in the branch:
 
  - Generics now support a few new options
- #:fallbacks specifies fallback method implementations for instances
  with no implementation
- #:fast-defaults specifies instances on a fast path, useful for
  built-in types
- #:defined-predicate gives a more intuitive and efficient interface
  than #:defined-table
- #:derive-property allows generics to piggy-back on existing struct
  properties
 
  - Sets are now a generic datatype through gen:set
- lists are now sets
- the built-in set types are now documented as hash sets
- there are mutable and weak hash sets
- you can define new set types quickly with define-custom-set-types
- most set operations are now methods with fallbacks
- sets now support -copy and -clear operations, plus mutating [!]
  versions of operations
 
  - Dictionaries have a few changes
- new macro define-custom-hash-types [*]
- most dict operations are now methods with fallbacks
- dicts now support -copy, -clear, -clear!, and -empty? operations
 
  I've run some benchmarks and performance of the various generic
 operations
  are comparable to the current HEAD, so there should be no major
 performance
  changes with this patch.
 
  [*] I've added define-custom-hash-types and define-custom-set-types
 rather
  than just adding make-custom-set akin to make-custom-hash because
  make-custom-hash is hard to use.  The documented behavior -- that any
 custom
  hash is equal to any other created with the same bindings and
 predicates /
  hash functions -- was never true and can be expensive or at least
 tricky to
  implement.  It seemed more sensible to just remove the erroneous
  documentation on make-custom-hash, and add the definition form to create
  constructors for new, explicitly-compatible dict and set types.  Both
  definition forms bind predicates and constructors for new (set or dict)
  types with immutable, mutable, and weak variants that inter-operate.
 
  If there are no serious issues brought up in the next day or two, I'll
  push it to the development branch, since our current release process
 isn't
  following HEAD.
 
  Carl Eastlund
 
 
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 


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


Re: [racket-dev] Generics updates

2013-08-01 Thread Carl Eastlund
Ah, yes, set-stream isn't primitive because it can be derived if you have
set-first and either set-rest or set-remove.  And I know there are
dependency cycles, this is intentional so that you can implement any one of
several related things, but most of them were supposed to go all the way
down to primitive methods (in some sense) if all else failed.

Would it be better to just remove the primitve / derived distinction,
since it's somewhat artificial, and leave it up to the individual method
descriptions?  Is there some better way I should be describing things?

Carl Eastlund


On Thu, Aug 1, 2013 at 6:51 PM, Stephen Chang stch...@ccs.neu.edu wrote:

  For the other part, I either should have made it as you say -- implement
 the  primitive ones and you get the others -- or else I should have
 clearly
  documented the relationship somewhere.

 You did document the dependencies, but some of them are circular, ie
 some derived rely on other derived. I'd definitely be happy to patch
 things myself, but I guess I dont have a concrete complaint yet :),
 only that the distinctions feel somewhat arbitrary and did not match
 my initial intuition, which is why I'm looking for additional insight.


  Do you have examples of which ones don't come for free with the
 primitive
  methods?

 Very few of the derived come free because most rely on set-stream,
 but set-stream is not primitive which is why I thought there might
 be a distinction between iterable sets and non-iterable.




 
  Carl Eastlund
 
 
  On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang stch...@ccs.neu.edu
 wrote:
 
  Just played a bit with gen:set. It looks great and in particular the
  fallback implementations are very convenient.
 
  One comment: the distinction between primitive methods and derived
  methods confused me somewhat. Can you explain the reasoning for
  determining which is which?
 
  For example, when I first read the docs, I thought that if I
  implemented the primitives, I would get the derived, but that's not
  the case since some of the derived methods depend on each other.
  Reading the docs more thoroughly, it sort of seems like there's an
  implicit separation along the lines of iterability, ie, derived sets
  are iterable since many of the derived methods require set-stream,
  but that's not exactly right either.
 
 
  On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund c...@ccs.neu.edu wrote:
   After some fixes, mostly to contracts and documentation, I've pushed
 the
   new
   generics and set features to the master branch.
  
   Carl Eastlund
  
  
   On Tue, Jul 23, 2013 at 11:37 AM, Carl Eastlund c...@ccs.neu.edu
 wrote:
  
   My work on adding gen:set, and related changes to define-generics and
   gen:dict, is ready for review and (hopefully) to push to the master
   branch.
   The branch moved in the process of cleaning things up, it's now at:
  
 https://github.com/carl-eastlund/racket/tree/generics-from-scratch
  
   (The from scratch just refers to the process of rebuilding the git
   history, I didn't go out of my way to rewrite anything in the code
 base
   from
   scratch, although in some places a lot of code did move around.)
  
   What's new in the branch:
  
   - Generics now support a few new options
 - #:fallbacks specifies fallback method implementations for
 instances
   with no implementation
 - #:fast-defaults specifies instances on a fast path, useful for
   built-in types
 - #:defined-predicate gives a more intuitive and efficient
 interface
   than #:defined-table
 - #:derive-property allows generics to piggy-back on existing
 struct
   properties
  
   - Sets are now a generic datatype through gen:set
 - lists are now sets
 - the built-in set types are now documented as hash sets
 - there are mutable and weak hash sets
 - you can define new set types quickly with define-custom-set-types
 - most set operations are now methods with fallbacks
 - sets now support -copy and -clear operations, plus mutating [!]
   versions of operations
  
   - Dictionaries have a few changes
 - new macro define-custom-hash-types [*]
 - most dict operations are now methods with fallbacks
 - dicts now support -copy, -clear, -clear!, and -empty? operations
  
   I've run some benchmarks and performance of the various generic
   operations
   are comparable to the current HEAD, so there should be no major
   performance
   changes with this patch.
  
   [*] I've added define-custom-hash-types and define-custom-set-types
   rather
   than just adding make-custom-set akin to make-custom-hash because
   make-custom-hash is hard to use.  The documented behavior -- that any
   custom
   hash is equal to any other created with the same bindings and
   predicates /
   hash functions -- was never true and can be expensive or at least
   tricky to
   implement.  It seemed more sensible to just remove the erroneous
   documentation on make-custom-hash, and add the definition form

Re: [racket-dev] Generics updates

2013-08-01 Thread Carl Eastlund
No, that doesn't work.  If someone implements, say, an efficient subset?
test, then set=? should use that rather than iterating using set-stream
and set-member?.  You should use the highest-level methods you can, in
order to get the most out of an implementation.  Which is why I made all
the fallback implementations I did, to give implementers the best
flexibility possible for getting a good implementation of all methods for
the minimum possible effort on their part.

Similarly, I don't want to make set-stream primitive, because if someone
does implement set-first and set-rest, it should be derivable.

Carl Eastlund


On Thu, Aug 1, 2013 at 7:26 PM, Stephen Chang stch...@ccs.neu.edu wrote:

  Would it be better to just remove the primitve / derived distinction,
  since it's somewhat artificial, and leave it up to the individual method
  descriptions?  Is there some better way I should be describing things?

 Ok I can see now that there's no easy way to organize the methods.

 I think we should keep some distinction, since as a programmer it's
 good to know exactly what methods I have to implement. However, to me
 fallback implies that I should get it for free, so it seems most
 intuitive if derived methods only depend on primitive methods. Then
 for some subset of primitive methods that I implement, I should get
 the derived methods that depend on those primitives. I'll have to
 think more about what should be derived and primitive, but for now I
 think the easiest thing is to edit the docs to move set-stream (or
 some equivalent) into the primitive list?



 
  Carl Eastlund
 
 
  On Thu, Aug 1, 2013 at 6:51 PM, Stephen Chang stch...@ccs.neu.edu
 wrote:
 
   For the other part, I either should have made it as you say --
 implement
   the  primitive ones and you get the others -- or else I should have
   clearly
   documented the relationship somewhere.
 
  You did document the dependencies, but some of them are circular, ie
  some derived rely on other derived. I'd definitely be happy to patch
  things myself, but I guess I dont have a concrete complaint yet :),
  only that the distinctions feel somewhat arbitrary and did not match
  my initial intuition, which is why I'm looking for additional insight.
 
 
   Do you have examples of which ones don't come for free with the
   primitive
   methods?
 
  Very few of the derived come free because most rely on set-stream,
  but set-stream is not primitive which is why I thought there might
  be a distinction between iterable sets and non-iterable.
 
 
 
 
  
   Carl Eastlund
  
  
   On Thu, Aug 1, 2013 at 6:27 PM, Stephen Chang stch...@ccs.neu.edu
   wrote:
  
   Just played a bit with gen:set. It looks great and in particular the
   fallback implementations are very convenient.
  
   One comment: the distinction between primitive methods and
 derived
   methods confused me somewhat. Can you explain the reasoning for
   determining which is which?
  
   For example, when I first read the docs, I thought that if I
   implemented the primitives, I would get the derived, but that's not
   the case since some of the derived methods depend on each other.
   Reading the docs more thoroughly, it sort of seems like there's an
   implicit separation along the lines of iterability, ie, derived sets
   are iterable since many of the derived methods require set-stream,
   but that's not exactly right either.
  
  
   On Thu, Jul 25, 2013 at 1:58 PM, Carl Eastlund c...@ccs.neu.edu
 wrote:
After some fixes, mostly to contracts and documentation, I've
 pushed
the
new
generics and set features to the master branch.
   
Carl Eastlund
   
   
On Tue, Jul 23, 2013 at 11:37 AM, Carl Eastlund c...@ccs.neu.edu
wrote:
   
My work on adding gen:set, and related changes to define-generics
and
gen:dict, is ready for review and (hopefully) to push to the
 master
branch.
The branch moved in the process of cleaning things up, it's now
 at:
   
   
 https://github.com/carl-eastlund/racket/tree/generics-from-scratch
   
(The from scratch just refers to the process of rebuilding the
 git
history, I didn't go out of my way to rewrite anything in the code
base
from
scratch, although in some places a lot of code did move around.)
   
What's new in the branch:
   
- Generics now support a few new options
  - #:fallbacks specifies fallback method implementations for
instances
with no implementation
  - #:fast-defaults specifies instances on a fast path, useful
 for
built-in types
  - #:defined-predicate gives a more intuitive and efficient
interface
than #:defined-table
  - #:derive-property allows generics to piggy-back on existing
struct
properties
   
- Sets are now a generic datatype through gen:set
  - lists are now sets
  - the built-in set types are now documented as hash sets
  - there are mutable and weak hash sets
  - you can define new set types

Re: [racket-dev] git submodule for native-library packages

2013-07-30 Thread Carl Eastlund
I looked into git-subtree, and as I recall it, nothing in the setup recalls
what subtree is used for what.  Every git-subtree command you enter has to
be fully explicit, which is a big hassle.  Whereas git-submodule saves its
state in the repository, so it knows what it's being used for and you only
need to do it once.  Hopefully I misunderstood git-subtree, but if I
didn't, I found its interface disappointing.

Carl Eastlund


On Tue, Jul 30, 2013 at 5:41 PM, Asumu Takikawa as...@ccs.neu.edu wrote:

 On 2013-07-27 07:10:54 -0600, Matthew Flatt wrote:
  I'm still unsure that submodules are going to be useful for managing a
  kind of main-distribution repository with references to package
  repositories.

 Perhaps it would be worth considering using the git subtree feature
 instead of submodules for the rest of the repository (just to clarify,
 I'm not saying we should reconsider submodules for native-pkgs).

 Description here:

   https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

 In particular, this aspect seems useful for us:
   you can also extract the entire history of a subdirectory from
your project and make it into a standalone project

 From what I understand (not having used them yet), subtrees also enable
 end users of our main repo to just do a clone without any special
 consideration for the subtrees. Only package maintainers would have to
 occasionally update the subtrees in the main repo to pull in changes
 from their own package repos.

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

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


Re: [racket-dev] Using new package system: rackunit still pointing to collects?

2013-07-29 Thread Carl Eastlund
Yes, instead you want to run 'make' at the top of the repository.

Carl Eastlund

--
WARNING!  Poorly-typed cell phone email precedes.
On Jul 29, 2013 12:23 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 I've done a complete nuke of my local racket install, and many things have
 just broken. The two problems that affect me the most are the disappearance
 of raco doc and rackunit.
 Is there a new incantation other than
  ./configure ; make ; make install
 in racket/src

 or am I experiencing growing pains with the package system that need
 fixing?

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

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


[racket-dev] Broken docs

2013-07-25 Thread Carl Eastlund
I have multiple PLT trees on my machine, and right now the one in
/Users/cce/git/racket/generics seems to want to use the Scribble search
page from the one in /Users/cce/git/racket/plt.  Except, once this problem
came up, I deleted both of them, and rebuilt the one in generics from
scratch.  It still wants to use the search page from the other, now
nonexistent, tree.  Anyone know what might be going wrong?  I'm going
insane here trying to figure out what lingering reference there might be to
the now-removed tree.

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


Re: [racket-dev] Broken docs

2013-07-25 Thread Carl Eastlund
That fixed it, thanks Matthew!

Carl Eastlund


On Thu, Jul 25, 2013 at 11:54 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 When you visit the main user-specific documentation page, then a cookie
 is installed to remember that page as your user-specific page (which
 would include user-scoped packages). The search box uses that cookie
 (on pages that are in the installation) to jump back to user-specific
 documentation for a search. So, it sounds like the cookie is giving you
 trouble.

 At Thu, 25 Jul 2013 02:46:05 -0400, Carl Eastlund wrote:
  I have multiple PLT trees on my machine, and right now the one in
  /Users/cce/git/racket/generics seems to want to use the Scribble search
  page from the one in /Users/cce/git/racket/plt.  Except, once this
 problem
  came up, I deleted both of them, and rebuilt the one in generics from
  scratch.  It still wants to use the search page from the other, now
  nonexistent, tree.  Anyone know what might be going wrong?  I'm going
  insane here trying to figure out what lingering reference there might be
 to
  the now-removed tree.
 
  Carl Eastlund
  _
Racket Developers list:
http://lists.racket-lang.org/dev


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


Re: [racket-dev] Generics updates

2013-07-25 Thread Carl Eastlund
After some fixes, mostly to contracts and documentation, I've pushed the
new generics and set features to the master branch.

Carl Eastlund


On Tue, Jul 23, 2013 at 11:37 AM, Carl Eastlund c...@ccs.neu.edu wrote:

 My work on adding gen:set, and related changes to define-generics and
 gen:dict, is ready for review and (hopefully) to push to the master
 branch.  The branch moved in the process of cleaning things up, it's now at:

   https://github.com/carl-eastlund/racket/tree/generics-from-scratch

 (The from scratch just refers to the process of rebuilding the git
 history, I didn't go out of my way to rewrite anything in the code base
 from scratch, although in some places a lot of code did move around.)

 What's new in the branch:

 - Generics now support a few new options
   - #:fallbacks specifies fallback method implementations for instances
 with no implementation
   - #:fast-defaults specifies instances on a fast path, useful for
 built-in types
   - #:defined-predicate gives a more intuitive and efficient interface
 than #:defined-table
   - #:derive-property allows generics to piggy-back on existing struct
 properties

 - Sets are now a generic datatype through gen:set
   - lists are now sets
   - the built-in set types are now documented as hash sets
   - there are mutable and weak hash sets
   - you can define new set types quickly with define-custom-set-types
   - most set operations are now methods with fallbacks
   - sets now support -copy and -clear operations, plus mutating [!]
 versions of operations

 - Dictionaries have a few changes
   - new macro define-custom-hash-types [*]
   - most dict operations are now methods with fallbacks
   - dicts now support -copy, -clear, -clear!, and -empty? operations

 I've run some benchmarks and performance of the various generic operations
 are comparable to the current HEAD, so there should be no major performance
 changes with this patch.

 [*] I've added define-custom-hash-types and define-custom-set-types rather
 than just adding make-custom-set akin to make-custom-hash because
 make-custom-hash is hard to use.  The documented behavior -- that any
 custom hash is equal to any other created with the same bindings and
 predicates / hash functions -- was never true and can be expensive or at
 least tricky to implement.  It seemed more sensible to just remove the
 erroneous documentation on make-custom-hash, and add the definition form to
 create constructors for new, explicitly-compatible dict and set types.
 Both definition forms bind predicates and constructors for new (set or
 dict) types with immutable, mutable, and weak variants that inter-operate.

 If there are no serious issues brought up in the next day or two, I'll
 push it to the development branch, since our current release process isn't
 following HEAD.

 Carl Eastlund

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


Re: [racket-dev] package scopes

2013-07-25 Thread Carl Eastlund
I currently use PLTADDONDIR to make each repo's packages install to a
different place, within the repo tree, so that they're both separate, and
get cleaned up if and when I remove the repo.  Will that still work with
these changes?

Carl Eastlund


On Thu, Jul 25, 2013 at 1:59 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 We currently have three packages scopes:

  * 'installation --- specific to an installation of Racket, where
 package files are written into the installation (for all users of
 the installation)

  * 'user --- specific to a user and version, where packages files are
 written to a user-specific location

  * 'shared --- specific to a user, but not to a version of Racket

 I think we should change to two:

  * 'installation --- like now

  * 'user --- specific to a user and installation, but where
 installations are identified by a configurable name (as opposed to,
 say, the installation's path)

 That is, every installation has a name. For a release, the name
 defaults to the release version. For a snapshot, the name defaults to
 snapshot --- which means that when you throw away your snapshot and
 install a new one, then you keep your package installations.
 (Distributors of releases and snapshots can adjust the default,
 obviously.) For a repository checkout, the name defaults to checkout
 --- which means that you keep your package installations when you `git
 pull' and the version changes.

 An installation name would be stored in the same configuration file
 that is used for package catalogs. A user who wants multiple snapshot
 installations, git-repo checkouts with different package sets, or
 multiple installations of Racket v6.0 can adjust one installation's
 name in its configuration. Similarly, a user who really wants to share
 packages between Racket v6.0 and v6.1 can give the installations the
 same name.

 I think this change would make the 'user installation scope the right
 default for pretty much everyone, instead of trying to make the default
 'user under some circumstances and 'installation in others. I think it
 also covers the goal of 'shared better than 'shared does.

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


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


Re: [racket-dev] Generics updates

2013-07-24 Thread Carl Eastlund
Thanks for those pointers, Tobias, I'll get those fixed.

Carl Eastlund

On Wed, Jul 24, 2013 at 1:34 PM, Tobias Hammer tobias.ham...@dlr.de wrote:

 I really like the new set features, especially mutable sets and lists as
 sets.

 Two things i have notices:
 * The docs for set-intersect seem a bit mixed up with set-union stuff
 * I could not get set-intersect on lists working, what i've tried

 - (set-intersect '(1 2 3) '(2 3 4))
 ; set-add: contract violation
 ;   expected: set?
 ;   given: 2

 - (set-intersect (list-set '(1 2 3)) '(2 3 4))
 ; set-intersect: set arguments have incompatible equivalence predicates
 ;   first set: (set 1 2 3)
 ;   incompatible set: '(2 3 4)

 Tobias



 On Tue, 23 Jul 2013 17:37:15 +0200, Carl Eastlund c...@ccs.neu.edu wrote:

  My work on adding gen:set, and related changes to define-generics and
 gen:dict, is ready for review and (hopefully) to push to the master
 branch.  The branch moved in the process of cleaning things up, it's now
 at:

   
 https://github.com/carl-**eastlund/racket/tree/generics-**from-scratchhttps://github.com/carl-eastlund/racket/tree/generics-from-scratch

 (The from scratch just refers to the process of rebuilding the git
 history, I didn't go out of my way to rewrite anything in the code base
 from scratch, although in some places a lot of code did move around.)

 What's new in the branch:

 - Generics now support a few new options
   - #:fallbacks specifies fallback method implementations for instances
 with no implementation
   - #:fast-defaults specifies instances on a fast path, useful for
 built-in types
   - #:defined-predicate gives a more intuitive and efficient interface
 than
 #:defined-table
   - #:derive-property allows generics to piggy-back on existing struct
 properties

 - Sets are now a generic datatype through gen:set
   - lists are now sets
   - the built-in set types are now documented as hash sets
   - there are mutable and weak hash sets
   - you can define new set types quickly with define-custom-set-types
   - most set operations are now methods with fallbacks
   - sets now support -copy and -clear operations, plus mutating [!]
 versions of operations

 - Dictionaries have a few changes
   - new macro define-custom-hash-types [*]
   - most dict operations are now methods with fallbacks
   - dicts now support -copy, -clear, -clear!, and -empty? operations

 I've run some benchmarks and performance of the various generic operations
 are comparable to the current HEAD, so there should be no major
 performance
 changes with this patch.

 [*] I've added define-custom-hash-types and define-custom-set-types rather
 than just adding make-custom-set akin to make-custom-hash because
 make-custom-hash is hard to use.  The documented behavior -- that any
 custom hash is equal to any other created with the same bindings and
 predicates / hash functions -- was never true and can be expensive or at
 least tricky to implement.  It seemed more sensible to just remove the
 erroneous documentation on make-custom-hash, and add the definition form
 to
 create constructors for new, explicitly-compatible dict and set types.
 Both definition forms bind predicates and constructors for new (set or
 dict) types with immutable, mutable, and weak variants that inter-operate.

 If there are no serious issues brought up in the next day or two, I'll
 push
 it to the development branch, since our current release process isn't
 following HEAD.

 Carl Eastlund



 --
 --**---
 Tobias Hammer
 DLR / Robotics and Mechatronics Center (RMC)
 Muenchner Str. 20, D-82234 Wessling
 Tel.: 08153/28-1487
 Mail: tobias.ham...@dlr.de


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


[racket-dev] Generics updates

2013-07-23 Thread Carl Eastlund
My work on adding gen:set, and related changes to define-generics and
gen:dict, is ready for review and (hopefully) to push to the master
branch.  The branch moved in the process of cleaning things up, it's now at:

  https://github.com/carl-eastlund/racket/tree/generics-from-scratch

(The from scratch just refers to the process of rebuilding the git
history, I didn't go out of my way to rewrite anything in the code base
from scratch, although in some places a lot of code did move around.)

What's new in the branch:

- Generics now support a few new options
  - #:fallbacks specifies fallback method implementations for instances
with no implementation
  - #:fast-defaults specifies instances on a fast path, useful for
built-in types
  - #:defined-predicate gives a more intuitive and efficient interface than
#:defined-table
  - #:derive-property allows generics to piggy-back on existing struct
properties

- Sets are now a generic datatype through gen:set
  - lists are now sets
  - the built-in set types are now documented as hash sets
  - there are mutable and weak hash sets
  - you can define new set types quickly with define-custom-set-types
  - most set operations are now methods with fallbacks
  - sets now support -copy and -clear operations, plus mutating [!]
versions of operations

- Dictionaries have a few changes
  - new macro define-custom-hash-types [*]
  - most dict operations are now methods with fallbacks
  - dicts now support -copy, -clear, -clear!, and -empty? operations

I've run some benchmarks and performance of the various generic operations
are comparable to the current HEAD, so there should be no major performance
changes with this patch.

[*] I've added define-custom-hash-types and define-custom-set-types rather
than just adding make-custom-set akin to make-custom-hash because
make-custom-hash is hard to use.  The documented behavior -- that any
custom hash is equal to any other created with the same bindings and
predicates / hash functions -- was never true and can be expensive or at
least tricky to implement.  It seemed more sensible to just remove the
erroneous documentation on make-custom-hash, and add the definition form to
create constructors for new, explicitly-compatible dict and set types.
Both definition forms bind predicates and constructors for new (set or
dict) types with immutable, mutable, and weak variants that inter-operate.

If there are no serious issues brought up in the next day or two, I'll push
it to the development branch, since our current release process isn't
following HEAD.

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


Re: [racket-dev] `#%declare' and cross-phase persistent modules

2013-07-22 Thread Carl Eastlund
I get the same thing.  Also, the error message is particularly unhelpful.
It does not give the name of the module, a source location, or any
indication of what part of the module did not match what part of the
grammar in what way.  This is pretty much impossible to debug without
searching for every use of #%declare in the code base, and tracking down
every macro that can possibly expand into it.

Carl Eastlund


On Mon, Jul 22, 2013 at 5:14 PM, Stephen Chang stch...@ccs.neu.edu wrote:

 When compiling a fresh git head clone, I still get some cross-phase
 persistence errors (see below). Is this my fault, or are some packages
 still missing the declaration?


 raco setup: --- checking package dependencies ---
 raco setup:
 raco setup: error: during making for
 pkgs/errortrace-doc/errortrace/scribblings
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/errortrace-lib/errortrace
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/errortrace-lib/errortrace
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/errortrace-lib/errortrace
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/errortrace-lib/errortrace
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/errortrace-lib/errortrace
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/errortrace-lib/errortrace/lang
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/algol60
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/drscheme
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/drracket
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/drracket/private
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/scribble/tools
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/scribblings/tools
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/scribblings/tools
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/scribblings/tools
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/scribblings/drracket
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/drracket/private
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/scribblings/drracket
 raco setup:   module: does not satisfy cross-phase persistent grammar
 raco setup:
 raco setup: error: during making for pkgs/drracket/drracket/private
 raco setup:   module: does not satisfy cross-phase persistent grammar

 On Mon, Jul 22, 2013 at 12:18 PM, Matthew Flatt mfl...@cs.utah.edu
 wrote:
  As of v5.90.0.2 (pending), to declare a cross-phase persistent module,
  the module body must include
 
   (#%declare #:cross-phase-persistent)
 
  If the module declaration fails to meet the syntactic and import
  constraints of a cross-phase persistent module, then a syntax error is
  reported.
 
  This change is backward-incompatible in two ways:
 
   * Module declarations that are intended as cross-phase persistent
 won't be, anymore, until a `#%declare' form is added.
 
 I think cross-phase persistence is new enough --- and the old, quiet
 inference of persistence is sufficiently distressing --- that this
 won't be much of an issue.
 
   * The grammar of fully-expanded modules now includes `#%declare'
 forms.
 
 Programs that process fully-expanded modules are not common, but I
 expect that they exist outside of the main distribution. Those
 programs will need to be updated. Meanwhile, they won't break until
 they see a module that has a `#%declare' form, which won't happen
 often (at least for the near future).
 
  Although `#:cross-phase-persistent' is the only keyword recognized by
  `#%declare' initially, we'll add more. One possibility is a declaration
  that corresponds to `compile-enforce-module-constants'.
 
  I named the form

Re: [racket-dev] Pre-Release Checklist for v5.3.6

2013-07-22 Thread Carl Eastlund
On Mon, Jul 22, 2013 at 3:13 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:

 * Carl Eastlund c...@ccs.neu.edu
   - Dracula Tests (confirm that Dracula runs from PLaneT)


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


[racket-dev] Generics update

2013-07-10 Thread Carl Eastlund
I just pushed some of my work on generics in response to the mailing list
thread about define/generic.  What I pushed includes:

- define-generics now takes keyword arguments in any order, and allows them
before and/or after the method declarations
- #:defaults now works exactly like #:methods; it allows define/generic and
unsupported (absent) methods
- there is now a #:fallbacks option for define-generics

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


[racket-dev] generate-temporaries and #%top

2013-07-10 Thread Carl Eastlund
I'm having trouble with some of the features of define-generics in
top-level contexts.  Specifically, if I generate any names with
generate-temporaries, and there are forward references to them in the
expanded code, then the forward reference fails to expand because #%top is
not bound in the context of the temporary name.  This problem doesn't come
up in module or lexical bindings because all the definitions are bound, not
using #%top, by the time the forward reference is expanded.

So are generate-temporaries identifiers simply dangerous to use for
anything that might wind up at the top level?  Or is there a smarter way to
use them that I'm missing?

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


[racket-dev] Compilation dependencies

2013-07-10 Thread Carl Eastlund
raco setup:   pkgs/math/private/distributions/beta-dist.rkt:69:42: link:
module mismatch;
raco setup:possibly, bytecode file needs re-compile because
dependencies changed

I got this error after updating my git checkout and running make.  If
make and raco setup don't re-compile dependencies, what does?

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


Re: [racket-dev] Compilation dependencies

2013-07-10 Thread Carl Eastlund
There were some dependency errors:

raco setup: --- checking package dependencies ---
raco setup: found undeclared dependency:
raco setup:   mode: build
raco setup:   for package: errortrace-lib
raco setup:   on package: compatibility-lib
raco setup:   dependent source: zo-compile_rkt.dep
raco setup:   used module: (lib mzscheme/main.rkt)
raco setup: --- summary of missing dependencies ---
raco setup: undeclared dependency detected
raco setup:   for package: errortrace-lib
raco setup:   on package for build:
raco setup:compatibility-lib

Then there were a large number of errors of this form for vector-flvector
and flvector-list:

raco setup: error: during making for pkgs/math/private/distributions
raco setup:   pkgs/math/private/distributions/beta-dist.rkt:69:42: link:
module mismatch;
raco setup:possibly, bytecode file needs re-compile because
dependencies changed
raco setup: importing module: 'beta-dist
raco setup: exporting module:
/Users/cce/git/racket/generics/pkgs/math/private/flonum/flvector.rkt
raco setup: exporting phase level: 0
raco setup: internal explanation: variable not provided (directly or
indirectly)
raco setup: at: flvector-list
raco setup: in: flvector-list.16
raco setup: context...:
raco setup:  success
raco setup:
/Users/cce/git/racket/generics/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typed-racket.rkt:53:4
raco setup:
/Users/cce/git/racket/generics/racket/lib/collects/compiler/cm.rkt:345:0:
compile-zo*
raco setup:
/Users/cce/git/racket/generics/racket/lib/collects/compiler/cm.rkt:552:26
raco setup:
/Users/cce/git/racket/generics/racket/lib/collects/compiler/cm.rkt:545:42
raco setup:
/Users/cce/git/racket/generics/racket/lib/collects/compiler/cm.rkt:510:0:
maybe-compile-zo
raco setup:
/Users/cce/git/racket/generics/racket/lib/collects/compiler/cm.rkt:622:2:
do-check
raco setup:
/Users/cce/git/racket/generics/racket/lib/collects/compiler/cm.rkt:703:4
raco setup:
/Users/cce/git/racket/generics/racket/lib/collects/setup/parallel-do.rkt:420:20:
loop


Carl Eastlund


On Wed, Jul 10, 2013 at 8:08 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 At Wed, 10 Jul 2013 19:41:44 -0400, Carl Eastlund wrote:
  raco setup:   pkgs/math/private/distributions/beta-dist.rkt:69:42: link:
  module mismatch;
  raco setup:possibly, bytecode file needs re-compile because
  dependencies changed
 
  I got this error after updating my git checkout and running make.

 Can you show more of the error message and context?

 The exporting module and phase level may help debug the problem, and
 I wonder whether the lines before can provide any hints.



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


Re: [racket-dev] expand, local-expand, and syntax-procedure-converted-arguments-property

2013-07-10 Thread Carl Eastlund
Carl Eastlund


On Wed, Jul 10, 2013 at 11:28 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 At Wed, 10 Jul 2013 23:15:46 -0400, Ryan Culpepper wrote:
  On 07/10/2013 09:04 PM, Asumu Takikawa wrote:
   Hi all,
  
   I'm currently trying to fix the Typed Racket unit tests. I think I've
   narrowed down the issue to a certain syntax property for keyword
   functions.
  
   The issue is illustrated by the following example:
  
  #lang racket
  
  (require racket/file
   (for-syntax racket/file
   racket/keyword-transform))
  
  ;; the property is #f
  (begin-for-syntax
   (displayln
 (syntax-case (expand-syntax #'(copy-directory/files 1 2)) ()
   [(let-values (((temp1) _)
 ((temp2) _))
  (if _
  (#%plain-app1 copy-directory/files15 e1 ...)
  (#%plain-app2 copy-directory/files17 e2 ...)))
(syntax-procedure-converted-arguments-property
  #'copy-directory/files15)])))
  
  ;; property is syntax
  (begin-for-syntax
   (displayln
 (syntax-case (local-expand #'(copy-directory/files 1 2)
 'expression
  null) ()
   [(let-values (((temp1) _)
 ((temp2) _))
  (if _
  (#%plain-app1 copy-directory/files15 e1 ...)
  (#%plain-app2 copy-directory/files17 e2 ...)))
(syntax-procedure-converted-arguments-property
  #'copy-directory/files15)])))
  
   There are two syntax-time computations here. Both are expanding an
   application of a keyword function (one with local-expand, one with
   expand) and looking at the resulting syntax.
  
   The key point here is that I want to find the property looked up by
   `syntax-procedure-converted-arguments-property` on an output identifier
   because Typed Racket needs it to type-check the expansion.
  
   Unfortunately, as the comments indicate, only the second piece of code
   can find the property. The reason appears to be that the property key
 is
   actually a private `gensym`ed symbol and the two pieces of code appear
   to get separate instantiations of the kw.rkt module (perhaps at
 different
   phases).
  
   To check that, if I modify kw.rkt to use a plain symbol, both of the
   snippets above return the same property value.
  
   Anyone have any idea how I can keep using `expand` but still be able to
   look up the property?
 
  To get information about a phase-0 '#%app' expansion, you need to call
  the phase-1 version of 'syntax-procedure-converted-arguments-property'.
  That's going to require a bit of phase-crossing trickery, because the
  identifier you want to query is a phase-0 (dynamic) value, and you want
  the result as a phase-0 value, but the phase-1 function naturally
  consumes and produces phase-1 values.
 
  One solution is to use 'quote-syntax', 'eval', and 'phase1-eval' all
  together. Use 'eval' with 'quote-syntax' to convert the phase-0
  identifier to a phase-1 identifier. Use 'phase1-eval' to run the
  computation at phase 1 and capture the phase-1 result as a phase-0 value
  (also using 'quote-syntax').

 I haven't thought about this much, but would it make more sense to move
 the property key to a cross-phase persistent module (with a `protected'
 provide) in this case?


That came up on IRC.  I believe Asumu said the key is an uninterned
identifier, meaning it's a stateful value.  Right now, cross-phase
persistent modules can't store anything stateful other than generative
struct types.

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


[racket-dev] Package compatibility

2013-07-07 Thread Carl Eastlund
It seems to me our new package system runs into trouble if two people write
packages that use the same connection name.  Let's say we have two
packages, alice-tree and bob-tree, both of which provide the collection
data/red-black-tree, but both provide different interfaces (perhaps similar
functionality with different naming conventions).  It seems to me this is
not that unlikely to happen, but once it does, those two packages are
completely incompatible.  They can never meaningfully be installed on the
same system, and if they are, the behavior of any code depending on either
becomes undefined.

Have I got this right, or have I missed some detail?  If this is right, how
concerned are we about this feature?  The fact that packages are all
spliced into a single flat collection namespace of course leads to the
possibility of clashes like this, which can cause not just incompatibility
between alice-tree and bob-tree, but a complete schism wherein all code
depending on alice-tree at any level of indirection becomes completely
disjoint from all code depending on bob-tree at any level of indirection.
I've seen this kind of library incompatibility before, in the ACL2 books,
and I wrote a dissertation to try to solve it.  I hope we're not repeating
their mistake, but it seems like we have yet another flat namespace with no
resolution mechanism.

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


Re: [racket-dev] dependencies for `racket-test` package

2013-07-02 Thread Carl Eastlund
I believe the reason we disabled compilation was that tests weren't
constrained to depend only on the core.  Some tests may use planet
packages, etc.  Originally, this was mostly for rackunit, which was a
planet package.  This suggests to me that we should (a) remove the test
packages from the default distribution, and (b) re-enable compilation for
them.  That way the dependencies will be computed properly.  It also
suggests that if they aren't already included, perhaps we should add planet
packages to the list of things we consider among dependencies?

Carl Eastlund


On Tue, Jul 2, 2013 at 12:42 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 I'm pretty sure that racket-test needs to be split up. (For the
 initial cut, I just put the whole tests collection there.)

 I'm not sure about compiling tests for the purposes of dependency
 checking. It sounds ok, but I have a feeling that I'm forgetting some
 reason that we disabled compilation for tests.

 At Tue, 2 Jul 2013 12:20:57 -0400, Sam Tobin-Hochstadt wrote:
  Currently, the `racket-test` package has very few declared
  dependencies, but this is wrong. The checking in 'raco setup' doesn't
  catch this because the files aren't compiled, but at a minimum it
  depends on `unstable/debug` (currently a hidden part of
  `typed-racket-lib`) and some portions of htdp that aren't declared.
 
  This brings up (at least) 3 questions
 
  - What is it ok for `racket-test` to depend on?  I'd like this set to
  be small, so we can test the core without needing to build everything.
  - Should we compile the contents of `racket-test` so that we get
  dependency checking?
  - Should parts of `racket-test` be split up?
 
  I'd like to figure this out, but I don't have answers yet.
 
  Sam
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev


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


Re: [racket-dev] A broken contract test feature

2013-07-02 Thread Carl Eastlund
Could you simply forge the source location on the syntax object to make it
look like it's from a collection?

Carl Eastlund

On Tue, Jul 2, 2013 at 7:10 PM, Robby Findler
ro...@eecs.northwestern.eduwrote:

 I looked into this too and didn't come up with a good solution.

 It would be nice if there were a way to write the here's a path, please
 tell me which part to replace with pkg/something without too many
 dependencies, but I didn't try to see if that would be feasible.

 Meanwhile, I agree that just disabling that test is probably the way to go.

 Robby


 On Tue, Jul 2, 2013 at 5:57 PM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote:

 Currently, there's one test in 'contract-test.rktl' that fails.  The
 problem is that the test expects 'contract-test.rktl' to be in the
 main collects directory, but it isn't -- it's in the `racket-test`
 package.   What we want is to have it detect that it's in a package,
 but doing that has two problems. First, the relevant function is in
 `setup/private/setup-relative`, but should probably be exported
 publicly.  Second, it can't be used, because it uses the package
 system (of course) but the package system uses contracts in its
 implementation. For this reason, I've disabled the test for the
 moment, so that the core racket tests complete successfully [1].

 Unfortunately, this is a really nice, if small, feature of the
 contract system.  Any suggestions for how we can fix this?

 Sam

 [1] Why I care in will be clear in a subsequent email.



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


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


[racket-dev] Package management

2013-06-27 Thread Carl Eastlund
I just ran raco pkg show on a fresh install, and its output is huge now.
Of course, this is inevitable when we break the distribution up into many
packages, but it makes the tool unmanageable for routine use.  I'd like to
propose a way around this, that would also solve some of my normal
usability gripes with package managers.

I propose we have package roots -- roots to the forest of package
dependencies.  These are the packages the user actually wants; every other
installed package is pulled in as the dependencies to support these.  Then
raco pkg show can show just these packages, so in a fresh install we'd
just see racket or racket+gui or whatever.  We could add a flag to show
everything, when necessary.

This also gives us some room to automate removal of packages the user
doesn't need.  For instance, if I install package A which depends on B, C,
and D, of course raco pkg install will install B, C, and D.  If I remove
package A, currently B, C, and D are going to stay unless I explicitly
remove them, if I recall correctly.  If we base our system on a set of root
packages, then B, C, and D would be removable as soon as A is removed, if A
was a root and the others were not.  We could have raco pkg remove A
remove them immediately, or we could have some explicit raco pkg cleanup
to remove them.  Whichever way we go, we could add a flag to raco pkg
remove to swap behavior.  This would make cleaning up a lot easier when a
package has many dependencies.  It would also mean upgrading a package
whose dependencies have changed would allow the system to automatically
clean up dependencies that aren't needed any more.

I don't know how hard it would be to implement this, but I think it would
make the package system much more usable to present 90% of the interactions
solely in terms of the top-level packages the user cares about, and do all
the cleanup of dependency packages silently in the background when possible.

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


Re: [racket-dev] Package management

2013-06-27 Thread Carl Eastlund
That all sounds like exactly what I had in mind, with different (pretty
much better) terminology.

Carl Eastlund

On Thu, Jun 27, 2013 at 3:17 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 The package system has a notion of auto packages, which are packages
 that were automatically installed to satisfy dependencies. Also, `raco
 pkg remove' supports an `--auto' flag for automatically removing auto
 packages that have no non-auto packages depending on them.

 So, instead of adding package roots, one possibility is:

  * Make `raco pkg show' show only non-auto packages by default.

  * Change the `pkg-links' Makefile target to install only links for
packages needed by a particular package (which defaults to some sort
of main-distribution package), and to install links forced by
dependencies as auto.

 The second bullet is along a direction that things are moving, anyway.

 I think there will need to be some other refinements to auto mode. For
 example, if you have a package in auto mode and you try to install it,
 I think you get an already-installed error and the package stays in
 auto mode. But those are small changes, I think.

 Does this sound enough like what you had in mind?

 At Thu, 27 Jun 2013 12:53:59 -0400, Carl Eastlund wrote:
  I just ran raco pkg show on a fresh install, and its output is huge
 now.
  Of course, this is inevitable when we break the distribution up into many
  packages, but it makes the tool unmanageable for routine use.  I'd like
 to
  propose a way around this, that would also solve some of my normal
  usability gripes with package managers.
 
  I propose we have package roots -- roots to the forest of package
  dependencies.  These are the packages the user actually wants; every
 other
  installed package is pulled in as the dependencies to support these.
  Then
  raco pkg show can show just these packages, so in a fresh install we'd
  just see racket or racket+gui or whatever.  We could add a flag to
 show
  everything, when necessary.
 
  This also gives us some room to automate removal of packages the user
  doesn't need.  For instance, if I install package A which depends on B,
 C,
  and D, of course raco pkg install will install B, C, and D.  If I remove
  package A, currently B, C, and D are going to stay unless I explicitly
  remove them, if I recall correctly.  If we base our system on a set of
 root
  packages, then B, C, and D would be removable as soon as A is removed,
 if A
  was a root and the others were not.  We could have raco pkg remove A
  remove them immediately, or we could have some explicit raco pkg
 cleanup
  to remove them.  Whichever way we go, we could add a flag to raco pkg
  remove to swap behavior.  This would make cleaning up a lot easier when
 a
  package has many dependencies.  It would also mean upgrading a package
  whose dependencies have changed would allow the system to automatically
  clean up dependencies that aren't needed any more.
 
  I don't know how hard it would be to implement this, but I think it would
  make the package system much more usable to present 90% of the
 interactions
  solely in terms of the top-level packages the user cares about, and do
 all
  the cleanup of dependency packages silently in the background when
 possible.
 
  Carl Eastlund
  _
Racket Developers list:
http://lists.racket-lang.org/dev


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


Re: [racket-dev] Things we could move out of the core

2013-06-26 Thread Carl Eastlund
What does being so fundamental have to do with being in the core vs being
in a package?  We should not confuse putting things in packages with making
them second-class concepts.  We can put racket/sandbox in a package without
necessarily making it any less fundamental to Racket.

Carl Eastlund

On Wed, Jun 26, 2013 at 8:46 AM, Matthias Felleisen matth...@ccs.neu.eduwrote:


 In general I agree with Robby on the definition of the core as minimum
 stuff to get pkgs running and we should be picky about what goes in. BUT,
 as a small addendum, I think the idea of sandboxing is so fundamental, I'd
 rather see the idea (not necessarily the current implementation) become a
 part of the core.

 -- Matthias


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


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


[racket-dev] Difficulty running racket tests

2013-06-22 Thread Carl Eastlund
I get the following error when I try to run tests/racket/quiet.rktl:

Section(basic)
Section(unicode)
Section(rx)
Section(reading)
Section(readtable)
Section(printing)
Section(macro)
Section(syntax)
Section(procs)
Section(stx)
Section(module)
ERROR: default-load-handler: cannot open module file
  module path:
#path:/Users/cce/git/racket/plt/build/native-pkgs/gui-x86_64-macosx/racket/string.rkt
  path:
/Users/cce/git/racket/plt/build/native-pkgs/gui-x86_64-macosx/racket/string.rkt
  system error: No such file or directory; errno=2

Anyone know what's up?

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


Re: [racket-dev] ready for the package switch?

2013-06-18 Thread Carl Eastlund
I'm rebasing my generic-sets branch onto the pkg2 branch to make sure that
rebasing works well.  Just using the default rebase options hasn't worked,
it doesn't figure out to follow the renames.  The following command seems
to be working, however; it may work for other people as well:

  git rebase -s recursive -X rename-threshold=50% mflatt/pkg2

This tells git that any files that are at least 50% similar (I guess by
line count?) are considered renamed versions of each other, and I guess
gives it permission to do the necessary, somewhat expensive search to
figure out which files to change in the rebased version instead of the ones
you actually changed in the original.  I also had to run the following
command first:

  git config merge.renameLimit 10

Otherwise git won't use the rename-threshold, because there are too many
files to consider in our repository and it doesn't believe you really want
it to do _that much_ work.  You can revert this afterward with:

  git config --unset merge.renameLimit

rantI don't understand why version control systems don't take directories
and renames more seriously, because this stuff is part of the development
cycle and should be recorded like any other change./rant

Anyway, if any of you out there are having trouble rebasing onto Matthew's
packages branch, try the commands above.

Carl Eastlund

On Tue, Jun 18, 2013 at 12:47 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Here's the latest (in a pkg2 branch):

  https://github.com/mflatt/racket/tree/pkg2

 Because this change will break all sorts of things in the short run,
 I'd like to feel more confident that enough of us are ready before
 merging it to the main Racket repository.

 So, vote in favor of the reorganization like this:

  1. Try the branch:

   git clone https://github.com/mflatt/racket.git
   cd racket
   git checkout pkg2
   make
   racket/bin/drracket

  2. Reply to the list to say that it works and we should merge it.

  3. If you have code in pkgs, be ready to help get that code into the
 right shape/packages after the merge.

 Thanks!


 (We haven't yet changed anything about single-collection versus
 multi-collection packages. That's currently planned for right after the
 merge.)

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


Re: [racket-dev] hash-list stability?

2013-06-18 Thread Carl Eastlund
On Tue, Jun 18, 2013 at 3:21 PM, Dan Liebgold dan.liebg...@gmail.comwrote:

 According to the docs, hash-list returns a list in an unspecified order.
  Can anyone tell me a little about how hash-list might return two
 different orders give the same hash table? Possibly across different
 invocations of Racket?

 Thanks,
 --
 Dan Liebgold[dan.liebg...@gmail.com]


Different invocations of Racket could do it; for instance, eq-hash-code
assigns hash codes sequentially to objects on demand, so if objects were
hashed in a different order nondeterministically, they would be put in a
table in a different order.  Adding or removing elements via mutation might
also cause a table to be resized, and that might shuffle around the
existing/remaining elements and cause them to be in a different order.

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


Re: [racket-dev] ready for the package switch?

2013-06-18 Thread Carl Eastlund
On Tue, Jun 18, 2013 at 2:02 PM, Eli Barzilay e...@barzilay.org wrote:

 20 minutes ago, Carl Eastlund wrote:
  [...]
 
git rebase -s recursive -X rename-threshold=50% mflatt/pkg2

 From a brief reading, I think that you're much better off with
 -X subtree=/some/path.  There's also a subtree strategy, which you'd
 get with -s subtree, but it is guessing how to do the path shifting.


I thought that too, but it didn't work when I tried it.  Some of my files
need to go in racket/lib, some in pkgs/racket-tests, and I think there
might have been a third place.  So unless everything is uniformly going to
the same place, the subtree options don't help.

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


Re: [racket-dev] ready for the package switch?

2013-06-18 Thread Carl Eastlund
I ran 'make', after rebasing, and eventually got this error:

pkg: missing dependencies
 for package: pkgs/gui-pkgs/gui-lib
 missing packages:
   gui-x86_64-macosx

Anyone know what might have gone wrong?

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


[racket-dev] Generics

2013-06-17 Thread Carl Eastlund
I have a long-running branch on github where I've been working on making
the set datatype generic the way dictionaries are, and improving the
generic system to support that effort.  Some of the people here at
Northeastern know about it, but I should probably make more people aware of
the work.  This is still a work in progress, it will be a while before it's
ready for final review and push.

  https://github.com/carl-eastlund/racket/tree/generic-sets

For sets, the main purpose has been to add gen:set and allow the set
datatype to be extended.  Along with that, I've added mutable sets and
make-custom-set, akin to make-custom-hash, and made lists usable as sets
based on equal? comparisons.

I've made an effort to put a lot of methods in gen:set, rather than the
bare minimum to make a set work.  My goal  is for an implementer to provide
whatever subset of the operations is necessary or desirable for a given set
representation, and have fallback implementations that will automatically
be used for other methods.  For example, a simple representation might
implement only set-member? and set-add, leaving set-union to the default
behavior using repeated set-add.  A more clever representation, such as
red-black tree sets, might have a custom efficient set-union operation.

At first I encoded this pattern by having separate back-end methods for
implementers to provide via gen:set, and wrapper functions that called set
operations if present and used default implementations otherwise.  But this
is cumbersome to program, and probably other generics will want it.  So I
extended define-generics to take a #:fallbacks option.  Now generic methods
can be given a fallback implementation in terms of the other methods that
will be used for any representations that do not provide a specific
implementation.

I have also added a #:extend option to define-generics, so a new generic
method group can extend one or more others.  If generic method group A
extends B and C, then implementations of methods for A should include any
definitions for the methods of B and C, and the new type will belong to all
three of A, B, and C.  This feature is more speculative than #:fallbacks; I
don't have a use for it in sets, but I think it would be valuable if we
make pervasive use of generics in the near future.

It would be much more convenient to use generics with #:extend if structure
properties supported diamond-shaped derivation graphs.  That is, if
property A derives B and C, and B and C each derive D, currently
make-struct-type raises an error because an implementation of A results in
multiple implementations of D.  This prevents some natural patterns of
related generics.  It would be nice to have some way of disambiguating
implementations to allow this, for instance if a struct type directly
provides an implementation for property D, it overrides any derived from A,
B, and C so that they can all coexist.

Right now I'm working on the behavior of make-custom-set, which has raised
some questions about the behavior of make-custom-hash.  I think I'll save
that discussion for a separate email in the near future, so as to keep to
more or less one topic and not go sprawling on for pages.  More pages, I
mean.

Anyway, I hope this is all stuff that looks good to people, because I've
put a lot of work into it, but I'm open to feedback if I've taken a wrong
turn somewhere.

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


Re: [racket-dev] Racket build dependencies

2013-06-14 Thread Carl Eastlund
I've pushed the changes; syntax/modcode now exports get-module-path, which
returns the path of the most up-to-date file for a module, along with a
symbol indicating whether that is a source file, bytecode file, or native
library.  It also exports get-metadata-path, which constructs derived path
names based on PLTCOMPILEDROOTS and similar settings.  Thanks to Matthew
for reviewing the diff.

Carl Eastlund


On Mon, Jun 10, 2013 at 12:38 AM, Carl Eastlund c...@ccs.neu.edu wrote:

 It looks like get-module-code from syntax/modcode does what I want
 internally.  I've submitted a pull request on github in which I've split
 out the two extra functions I need using the functionality that exists.  I
 modernized the Racket style in that file before making the changes --
 turning let into define and so forth.  That makes this a fairly big change,
 line-by-line; sorry about that, I know it makes reading the diff tougher,
 but it made it easier to figure out what I was working with in the file.

 Carl Eastlund

 On Sun, Jun 9, 2013 at 10:29 AM, Carl Eastlund c...@ccs.neu.edu wrote:

 I'm trying to make a raco make-like command for ACL2 certification of
 Dracula programs.  Given a Racket program written using the Dracula
 language, the command extracts a proof obligation, saves it as a .lisp
 file, and runs ACL2 on it.  There are a couple pieces of the Racket build
 system that I don't know how to get at, in making this process work.

 (1) I don't want to recreate the proof obligation files if they are
 up-to-date.  For this I need to get the name of the compiled .zo file for a
 module for comparison.  Is this functionality available somewhere?  I might
 also need the path of the module's source code, but I assume that's what
 resolved-module-path-name gives me.  Right?

 (2) I want to respect settings like PLTCOMPILEDROOTS when deciding where
 to save the proof obligation file.  Basically I want to mangle the module's
 source file name the same way as compilation does, except instead of
 SOURCE_rkt.zo I want to create SOURCE_rkt.lisp or some such.  Is _this_
 functionality available somewhere?

 I think that's all I would need to get started.  Any help would be
 appreciated, thanks.

 Carl Eastlund



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


Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

2013-06-14 Thread Carl Eastlund
I vote for this change.  I'll happily update my package in order to make it
easier for others to contribute new ones.

Carl Eastlund


On Fri, Jun 14, 2013 at 10:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 I think more people need to speak up on this question --- particularly
 authors of existing packages, since the current proposal necessitates
 an update to each existing package.

 The proposal is to make single-package collections the default:

  * If a directory used as a package has no info.rkt file, then it is
treated as a single-collection package.

The single collection's name is the same as the package name (which
tends to be the directory name, but it depends on how you install
the package).

  * If a directory used as a package has an info.rkt file, but
info.rkt doesn't explicitly say that the package is
multi-collection, then it's still a single-collection package.

The info.rkt file might supply a name for the single collection,
instead of leaving it to the package name; supplying a name would be
a requirement for ring-0 packages.

 For each existing package, the author would need to add a line to the
 package's info.rkt to indicate that it is a multi-collection package
 (or change the layout to single-collection mode, with the caveat that
 the package won't work with v5.3.4).

 Any more votes for/against?

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

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


Re: [racket-dev] experience using the `pkg` branch

2013-06-14 Thread Carl Eastlund
Jay,

Thanks for the detailed summary.  Right now I think the biggest missing
piece of information when something goes wrong is which packages were
affected?.  If I download package A, and it pulls in B and C, and they
pull in D, E, and F, and then somewhere along the lines raco setup fails, I
now have six packages installed, and no clear idea which ones are working
fine and which ones need to be fixed.  If raco pkg could communicate with
raco setup in some way to associate files that failed with the packages
they came from, it would be very useful at the end to get a report like:
raco pkg successfully installed packages B, E, and F; raco setup reports
errors with the installation of A, C, and D.  That or a raco pkg status
command to look up similar information.  Otherwise the user is left to
track down the dependencies responsible for errors themselves, which can
very time consuming when each step of the search involves running raco
setup on some new subset of packages.

I'm sure this extra scrutiny and criticism for the package system isn't
easy, so let me take this moment to also say -- thanks so much for writing
the package system!  It wouldn't be worth all this nitpicking if it weren't
a great system; we've come a long way from distributing source code via
.plt files, to having something worth using to bundle up our core
software.

Carl Eastlund

On Fri, Jun 14, 2013 at 10:13 AM, Jay McCarthy jay.mccar...@gmail.comwrote:

 I'll try to respond to these four messages at the same time...

 Sam said,
  In addition to the larger point Robby makes, this can be pretty
  confusing.  For example, you can fail to install enough dependencies,
  I think.
 
  Another problem is that there's no way to know what to do to fix
  things.  Say there's an error in `raco setup` that's transient (the
  machine lost power, for example).  What command do I run to 'fix' the
  setup? I don't even know what collections were being installed.

 On Thu, Jun 13, 2013 at 9:27 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
  I know it runs it. I don't know why Jay writes The package system says
  something is installed when the files are in place and the link is made.
  From some perspective, that's its job.. I can't tell if there's some
  technical piece I'm missing or not (on the surface, these words sound
 almost
  lazy but I *KNOW* Jay is anything but lazy!)
 
  Robby
 
 
  On Thu, Jun 13, 2013 at 10:21 PM, Carl Eastlund c...@ccs.neu.edu wrote:
 
  It does run 'raco setup', it just doesn't have much to do in response
 to a
  failure, at least right now.
 
  Carl Eastlund
 
  On Thu, Jun 13, 2013 at 11:14 PM, Robby Findler
  ro...@eecs.northwestern.edu wrote:
 
  Also, Jay: can you explain more why 'raco setup' isn't something that
 we
  should think about as running inside the pkg manager? (I'm not
 saying that
  automatically rolling back packages is the right thing to do or
 anything
  like that, but I would like to understand the model you have better.)

 Short:

 I interpret these messages to be saying, raco pkg printed error
 messages and didn't say what was wrong or what I should do about
 it. The messages came from 'raco setup', of course, and 'raco pkg'
 gave no interpretation.

 As a simple first step, we can have 'raco pkg' observe the output of
 'raco setup' (which might require changing it) and if it gives any
 error message of any kind, end with a message like:

 raco pkg detected strange output during setup. This could mean there
 was a problem. If you would like to undo this command, run:

   raco pkg remove the-package-you-installed

 This sounds like a simple to change to make, but there's one big
 problem. After 'raco pkg update' runs, the undo command is much more
 complicated and scary in its own way

   raco pkg remove --force the-package-you-updated
   raco pkg install
 the-source-for-the-package-you-updated-at-the-old-git-commit

 But some package sources may not be possible to get back, such as an
 old tar ball that you downloaded and don't have any more.

 When raco pkg update runs normally, it leaves the old files in place
 until the end and then deletes them. It could put these into some sort
 of 'archive' location to facilitate that. But it's a big change and
 easy to get very wrong.

 Long:

 I also interpret these messages to be saying

 When raco pkg returns with exit status 0, the packages I asked to be
 install/updated should 'work'.

 This is a reasonable wish, but I don't think it can be enforced
 technically. Let's un-ravel worked-ness:

 1. Does the task I thought it would do

   Clearly no way to ensure this. No package system does this.

 2. Every file executes without errors

   This is what DrDr normally does and is too burdensome for every
   package, and includes problems of the next stage. No package system
   does this.

 3. Passes its test cases on my system

   CPAN is fairly unique in doing this upon install, but virtually no
   other package system does this. I don't think

Re: [racket-dev] experience using the `pkg` branch

2013-06-13 Thread Carl Eastlund
It does run 'raco setup', it just doesn't have much to do in response to a
failure, at least right now.

Carl Eastlund

On Thu, Jun 13, 2013 at 11:14 PM, Robby Findler ro...@eecs.northwestern.edu
 wrote:

 Also, Jay: can you explain more why 'raco setup' isn't something that we
 should think about as running inside the pkg manager? (I'm not saying
 that automatically rolling back packages is the right thing to do or
 anything like that, but I would like to understand the model you have
 better.)

 Robby

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


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


[racket-dev] Racket build dependencies

2013-06-09 Thread Carl Eastlund
I'm trying to make a raco make-like command for ACL2 certification of
Dracula programs.  Given a Racket program written using the Dracula
language, the command extracts a proof obligation, saves it as a .lisp
file, and runs ACL2 on it.  There are a couple pieces of the Racket build
system that I don't know how to get at, in making this process work.

(1) I don't want to recreate the proof obligation files if they are
up-to-date.  For this I need to get the name of the compiled .zo file for a
module for comparison.  Is this functionality available somewhere?  I might
also need the path of the module's source code, but I assume that's what
resolved-module-path-name gives me.  Right?

(2) I want to respect settings like PLTCOMPILEDROOTS when deciding where to
save the proof obligation file.  Basically I want to mangle the module's
source file name the same way as compilation does, except instead of
SOURCE_rkt.zo I want to create SOURCE_rkt.lisp or some such.  Is _this_
functionality available somewhere?

I think that's all I would need to get started.  Any help would be
appreciated, thanks.

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


Re: [racket-dev] Racket build dependencies

2013-06-09 Thread Carl Eastlund
It looks like get-module-code from syntax/modcode does what I want
internally.  I've submitted a pull request on github in which I've split
out the two extra functions I need using the functionality that exists.  I
modernized the Racket style in that file before making the changes --
turning let into define and so forth.  That makes this a fairly big change,
line-by-line; sorry about that, I know it makes reading the diff tougher,
but it made it easier to figure out what I was working with in the file.

Carl Eastlund

On Sun, Jun 9, 2013 at 10:29 AM, Carl Eastlund c...@ccs.neu.edu wrote:

 I'm trying to make a raco make-like command for ACL2 certification of
 Dracula programs.  Given a Racket program written using the Dracula
 language, the command extracts a proof obligation, saves it as a .lisp
 file, and runs ACL2 on it.  There are a couple pieces of the Racket build
 system that I don't know how to get at, in making this process work.

 (1) I don't want to recreate the proof obligation files if they are
 up-to-date.  For this I need to get the name of the compiled .zo file for a
 module for comparison.  Is this functionality available somewhere?  I might
 also need the path of the module's source code, but I assume that's what
 resolved-module-path-name gives me.  Right?

 (2) I want to respect settings like PLTCOMPILEDROOTS when deciding where
 to save the proof obligation file.  Basically I want to mangle the module's
 source file name the same way as compilation does, except instead of
 SOURCE_rkt.zo I want to create SOURCE_rkt.lisp or some such.  Is _this_
 functionality available somewhere?

 I think that's all I would need to get started.  Any help would be
 appreciated, thanks.

 Carl Eastlund

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


Re: [racket-dev] [plt] Push #26936: master branch updated

2013-06-06 Thread Carl Eastlund
Also if you're going to memoize things, why are you using assoc rather than
a hash table?  Or if at all possible, a weak hash table?

Carl Eastlund


On Thu, Jun 6, 2013 at 6:35 PM, Robby Findler
ro...@eecs.northwestern.eduwrote:

 Can't we do better than a memo table?


 On Thursday, June 6, 2013, wrote:

 stamourv has updated `master' from 5ea3a1ce6d to 6e8c9ed15a.
   http://git.racket-lang.org/plt/5ea3a1ce6d..6e8c9ed15a

 =[ 2 Commits ]==
 Directory summary:
   82.9% collects/racket/contract/private/
   17.0% collects/scribblings/reference/

 ~~

 d1df869 Vincent St-Amour stamo...@racket-lang.org 2013-06-06 18:02
 :
 | Document procedure-closure-contents-eq?.
 :
   M collects/scribblings/reference/procedures.scrbl | 5 +

 ~~

 6e8c9ed Vincent St-Amour stamo...@racket-lang.org 2013-06-06 18:31
 :
 | Memoize wrapped case- range contracts.
 |
 | Fixes failing contract tests.
 :
   M collects/racket/contract/private/arrow.rkt | 21 +++--

 =[ Overall Diff ]===

 collects/racket/contract/private/arrow.rkt
 ~~
 --- OLD/collects/racket/contract/private/arrow.rkt
 +++ NEW/collects/racket/contract/private/arrow.rkt
 @@ -1712,12 +1712,21 @@ v4 todo:
the domain of
#:swap? #t)))
   dom-ctcs+case-nums)
 -(map (λ (f)
 -   (define p (f rng-blame))
 -   (lambda args
 - (with-continuation-mark
 -  contract-continuation-mark-key
 blame
 -  (apply p args
 +(map (let ([memo '()])
 +   ;; to preserve
 procedure-closure-contents-eq?ness of the
 +   ;; wrapped procedures, memoize with f
 as the key.
 +   (λ (f)
 + (define target
 +   (assoc f memo
 procedure-closure-contents-eq?))
 + (if target
 + (cdr target)
 + (let* ([p   (f rng-blame)]
 +[new (lambda args
 +
 (with-continuation-mark
 +
  contract-continuation-mark-key blame
 +(apply p
 args)))])
 +   (set! memo (cons (cons f new)
 memo))
 +   new
   rng-ctcs)))
(define (chk val mtd?)
  (cond

 collects/scribblings/reference/procedures.scrbl
 ~~~
 --- OLD/collects/scribblings/reference/procedures.scrbl
 +++ NEW/collects/scribblings/reference/procedures.scrbl
 @@ -88,6 +88,11 @@ to the wrong number of arguments, the resulting error
 hides the first
  argument as if the procedure had been compiled with the
  @indexed-racket['method-arity-error] syntax property.}

 +@defproc[(procedure-closure-contents-eq? [proc1 procedure?]
 + [proc2 procedure?]) boolean?]{
 +Compares the contents of the closures of @racket[proc1] and
 @racket[proc2]
 +for equality by comparing closure elements pointwise using @racket[eq?]}
 +
  @; 
  @section{Keywords and Arity}


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


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


Re: [racket-dev] [plt] Push #26936: master branch updated

2013-06-06 Thread Carl Eastlund
Good point.  Might be an argument for a
procedure-closure-contents-hash-code function.  Of course, never mind that
if you can forego memoization entirely.

Carl Eastlund

On Thu, Jun 6, 2013 at 7:46 PM, Vincent St-Amour stamo...@ccs.neu.eduwrote:

 At Thu, 6 Jun 2013 18:39:57 -0400,
 Carl Eastlund wrote:
  Also if you're going to memoize things, why are you using assoc rather
 than
  a hash table?  Or if at all possible, a weak hash table?

 I'm using `procedure-closure-contents-eq?' as the equality predicate.
 AFAIK, there's no hash table for that.

 Vincent


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


[racket-dev] Unique identifiers

2013-05-31 Thread Carl Eastlund
I'm having trouble creating identifiers that are unique with respect to
free-identifier=? and that survive marshaling to compiled code.  The normal
source of fresh identifiers, generate-temporaries, only guarantees they are
unique with respect to bound-identifier=?.  The obvious alternative,
gensym, does not properly survive marshaling -- copies saved in different
.zo files load as distinct identifiers.  I've tried a few alternative
methods, none more successful than either of these.

Below, there are a few short files that show the difficulties and can be
used to test other methods.  The first, fresh.rkt, contains the procedure
used to create fresh identifiers.  The file original.rkt creates a fresh
identifier at compile time.  The file identical.rkt copies the identifier
from original.rkt using quote-syntax.  The file different.rkt creates
another fresh identifier at compile time.  The file check.rkt checks that
the identifiers from original.rkt and identical.rkt are free-identifier=?
to each other, and that the identifiers from original.rkt and different.rkt
are not free-identifier=? to each other.  To run a test, first update
fresh.rkt to use the appropriate method for creating identifiers, then run
raco make check.rkt.  Some of the methods work when simply running
racket check.rkt, but raco make marshals the identifiers to .zo files
and exposes more problems.

Can anyone suggest an implementation that would work here?

; fresh.rkt
#lang racket
(begin-for-syntax
  (require racket/syntax)
  (define (fresh)
;; does not guarantee free-identifier=?
#;(generate-temporary)
;; does not survive marshaling
#;(gensym)
;; also does not survive marshaling
(begin
  (define id0 (datum-syntax #false 'fresh))
  (define ctx (syntax-local-make-definition-context))
  (syntax-local-bind-syntaxes (list id0) #false ctx)
  (internal-definition-context-seal ctx)
  (internal-definition-context-apply ctx id0)))
  (provide fresh))

; original.rkt
#lang racket
(require fresh.rkt)
(define-syntax (macro stx)
  (with-syntax {[name (fresh)]}
#'(begin-for-syntax
(define original (quote-syntax name))
(provide original
(macro)

; identical.rkt
#lang racket
(require original.rkt)
(define-syntax (macro stx)
  (with-syntax {[orig original]}
#'(begin-for-syntax
(define identical (quote-syntax orig))
(provide identical
(macro)

; different.rkt
#lang racket
(require fresh.rkt)
(define-syntax (macro stx)
  (with-syntax {[name (fresh)]}
#'(begin-for-syntax
(define different (quote-syntax name))
(provide different
(macro)

; check.rkt
#lang racket
(require fresh.rkt original.rkt identical.rkt different.rkt)
(begin-for-syntax
  (unless (free-identifier=? original identical)
(error 'fresh ~v != ~v\n original identical))
  (when (free-identifier=? original different)
(error 'fresh ~v == ~v\n original different)))

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


Re: [racket-dev] Unique identifiers

2013-05-31 Thread Carl Eastlund
I want a non-probabilistic guarantee of uniqueness, partly because I'd
rather not rely on something nondeterministic, and partly because in an
ideal solution, I'd like to have control over the printed names of these
identifiers.

Carl Eastlund

On Fri, May 31, 2013 at 9:27 AM, Eric Dobson eric.n.dob...@gmail.comwrote:

 What does unique mean in this context? Does probabilistically unique
 work? If so could you form an identifier with the symbolic form
 unique-id-+UUID?

 On Fri, May 31, 2013 at 8:20 AM, Carl Eastlund c...@ccs.neu.edu wrote:
  I'm having trouble creating identifiers that are unique with respect to
  free-identifier=? and that survive marshaling to compiled code.  The
 normal
  source of fresh identifiers, generate-temporaries, only guarantees they
 are
  unique with respect to bound-identifier=?.  The obvious alternative,
 gensym,
  does not properly survive marshaling -- copies saved in different .zo
 files
  load as distinct identifiers.  I've tried a few alternative methods, none
  more successful than either of these.
 
  Below, there are a few short files that show the difficulties and can be
  used to test other methods.  The first, fresh.rkt, contains the procedure
  used to create fresh identifiers.  The file original.rkt creates a fresh
  identifier at compile time.  The file identical.rkt copies the identifier
  from original.rkt using quote-syntax.  The file different.rkt creates
  another fresh identifier at compile time.  The file check.rkt checks that
  the identifiers from original.rkt and identical.rkt are
 free-identifier=? to
  each other, and that the identifiers from original.rkt and different.rkt
 are
  not free-identifier=? to each other.  To run a test, first update
 fresh.rkt
  to use the appropriate method for creating identifiers, then run raco
 make
  check.rkt.  Some of the methods work when simply running racket
  check.rkt, but raco make marshals the identifiers to .zo files and
  exposes more problems.
 
  Can anyone suggest an implementation that would work here?
 
  ; fresh.rkt
  #lang racket
  (begin-for-syntax
(require racket/syntax)
(define (fresh)
  ;; does not guarantee free-identifier=?
  #;(generate-temporary)
  ;; does not survive marshaling
  #;(gensym)
  ;; also does not survive marshaling
  (begin
(define id0 (datum-syntax #false 'fresh))
(define ctx (syntax-local-make-definition-context))
(syntax-local-bind-syntaxes (list id0) #false ctx)
(internal-definition-context-seal ctx)
(internal-definition-context-apply ctx id0)))
(provide fresh))
 
  ; original.rkt
  #lang racket
  (require fresh.rkt)
  (define-syntax (macro stx)
(with-syntax {[name (fresh)]}
  #'(begin-for-syntax
  (define original (quote-syntax name))
  (provide original
  (macro)
 
  ; identical.rkt
  #lang racket
  (require original.rkt)
  (define-syntax (macro stx)
(with-syntax {[orig original]}
  #'(begin-for-syntax
  (define identical (quote-syntax orig))
  (provide identical
  (macro)
 
  ; different.rkt
  #lang racket
  (require fresh.rkt)
  (define-syntax (macro stx)
(with-syntax {[name (fresh)]}
  #'(begin-for-syntax
  (define different (quote-syntax name))
  (provide different
  (macro)
 
  ; check.rkt
  #lang racket
  (require fresh.rkt original.rkt identical.rkt different.rkt)
  (begin-for-syntax
(unless (free-identifier=? original identical)
  (error 'fresh ~v != ~v\n original identical))
(when (free-identifier=? original different)
  (error 'fresh ~v == ~v\n original different)))
 
  --
  Carl Eastlund
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 


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


Re: [racket-dev] Unique identifiers

2013-05-31 Thread Carl Eastlund
Even worse, I can't even reliably make identifiers that are unique with
respect to bound-identifier=?, because marks don't survive marshaling any
better than other unique values like internal definition contexts or
uninterned symbols.  I checked this by changing fresh to run
generate-temporary and check.rkt to use bound-identifier=?.

The problem is pretty clearly that I'm using these identifiers without
binding them to anything, and that's not what identifiers are for.  I
either need a way to actually bind these things to _something_, or I need
to give up on identifiers for this purpose.  So unless someone has a
breakthrough and can solve this problem purely using identifiers, I'll look
to other kinds of solutions for now.

Carl Eastlund

On Fri, May 31, 2013 at 9:20 AM, Carl Eastlund c...@ccs.neu.edu wrote:

 I'm having trouble creating identifiers that are unique with respect to
 free-identifier=? and that survive marshaling to compiled code.  The normal
 source of fresh identifiers, generate-temporaries, only guarantees they are
 unique with respect to bound-identifier=?.  The obvious alternative,
 gensym, does not properly survive marshaling -- copies saved in different
 .zo files load as distinct identifiers.  I've tried a few alternative
 methods, none more successful than either of these.

 Below, there are a few short files that show the difficulties and can be
 used to test other methods.  The first, fresh.rkt, contains the procedure
 used to create fresh identifiers.  The file original.rkt creates a fresh
 identifier at compile time.  The file identical.rkt copies the identifier
 from original.rkt using quote-syntax.  The file different.rkt creates
 another fresh identifier at compile time.  The file check.rkt checks that
 the identifiers from original.rkt and identical.rkt are free-identifier=?
 to each other, and that the identifiers from original.rkt and different.rkt
 are not free-identifier=? to each other.  To run a test, first update
 fresh.rkt to use the appropriate method for creating identifiers, then run
 raco make check.rkt.  Some of the methods work when simply running
 racket check.rkt, but raco make marshals the identifiers to .zo files
 and exposes more problems.

 Can anyone suggest an implementation that would work here?

 ; fresh.rkt
 #lang racket
 (begin-for-syntax
   (require racket/syntax)
   (define (fresh)
 ;; does not guarantee free-identifier=?
 #;(generate-temporary)
 ;; does not survive marshaling
 #;(gensym)
 ;; also does not survive marshaling
 (begin
   (define id0 (datum-syntax #false 'fresh))
   (define ctx (syntax-local-make-definition-context))
   (syntax-local-bind-syntaxes (list id0) #false ctx)
   (internal-definition-context-seal ctx)
   (internal-definition-context-apply ctx id0)))
   (provide fresh))

 ; original.rkt
 #lang racket
 (require fresh.rkt)
 (define-syntax (macro stx)
   (with-syntax {[name (fresh)]}
 #'(begin-for-syntax
 (define original (quote-syntax name))
 (provide original
 (macro)

 ; identical.rkt
 #lang racket
 (require original.rkt)
 (define-syntax (macro stx)
   (with-syntax {[orig original]}
 #'(begin-for-syntax
 (define identical (quote-syntax orig))
 (provide identical
 (macro)

 ; different.rkt
 #lang racket
 (require fresh.rkt)
 (define-syntax (macro stx)
   (with-syntax {[name (fresh)]}
 #'(begin-for-syntax
 (define different (quote-syntax name))
 (provide different
 (macro)

 ; check.rkt
 #lang racket
 (require fresh.rkt original.rkt identical.rkt different.rkt)
 (begin-for-syntax
   (unless (free-identifier=? original identical)
 (error 'fresh ~v != ~v\n original identical))
   (when (free-identifier=? original different)
 (error 'fresh ~v == ~v\n original different)))

 --
 Carl Eastlund

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


Re: [racket-dev] Unique identifiers

2013-05-31 Thread Carl Eastlund
Thanks, I'll look into that.  It's implemented in the C code, but it looks
like it's effectively doing a combination of generate-temporary and
syntax-local-lift-module-end-declaration.  I don't think it gives me the
option of creating two fresh identifiers with the same printed name in the
same module and have them be immediately unique via free-identifier=?, as
the binding would not have taken effect yet, so to speak.  This is one of
those cases where my life would be so much easier if I could relax any one
of the constraints I'm working under.

Carl Eastlund


On Fri, May 31, 2013 at 9:58 AM, Eric Dobson eric.n.dob...@gmail.comwrote:

 If you replace all of your internal definition manipulation with
 (syntax-local-lift-expression #'#f), it passes your check.rkt. You
 don't have control over the names, but I'm guessing you could look
 into the implementation and see what it is doing to generate such
 names.

 On Fri, May 31, 2013 at 8:32 AM, Carl Eastlund c...@ccs.neu.edu wrote:
  I want a non-probabilistic guarantee of uniqueness, partly because I'd
  rather not rely on something nondeterministic, and partly because in an
  ideal solution, I'd like to have control over the printed names of these
  identifiers.
 
  Carl Eastlund
 
  On Fri, May 31, 2013 at 9:27 AM, Eric Dobson eric.n.dob...@gmail.com
  wrote:
 
  What does unique mean in this context? Does probabilistically unique
  work? If so could you form an identifier with the symbolic form
  unique-id-+UUID?
 
  On Fri, May 31, 2013 at 8:20 AM, Carl Eastlund c...@ccs.neu.edu wrote:
   I'm having trouble creating identifiers that are unique with respect
 to
   free-identifier=? and that survive marshaling to compiled code.  The
   normal
   source of fresh identifiers, generate-temporaries, only guarantees
 they
   are
   unique with respect to bound-identifier=?.  The obvious alternative,
   gensym,
   does not properly survive marshaling -- copies saved in different .zo
   files
   load as distinct identifiers.  I've tried a few alternative methods,
   none
   more successful than either of these.
  
   Below, there are a few short files that show the difficulties and can
 be
   used to test other methods.  The first, fresh.rkt, contains the
   procedure
   used to create fresh identifiers.  The file original.rkt creates a
 fresh
   identifier at compile time.  The file identical.rkt copies the
   identifier
   from original.rkt using quote-syntax.  The file different.rkt creates
   another fresh identifier at compile time.  The file check.rkt checks
   that
   the identifiers from original.rkt and identical.rkt are
   free-identifier=? to
   each other, and that the identifiers from original.rkt and
 different.rkt
   are
   not free-identifier=? to each other.  To run a test, first update
   fresh.rkt
   to use the appropriate method for creating identifiers, then run raco
   make
   check.rkt.  Some of the methods work when simply running racket
   check.rkt, but raco make marshals the identifiers to .zo files and
   exposes more problems.
  
   Can anyone suggest an implementation that would work here?
  
   ; fresh.rkt
   #lang racket
   (begin-for-syntax
 (require racket/syntax)
 (define (fresh)
   ;; does not guarantee free-identifier=?
   #;(generate-temporary)
   ;; does not survive marshaling
   #;(gensym)
   ;; also does not survive marshaling
   (begin
 (define id0 (datum-syntax #false 'fresh))
 (define ctx (syntax-local-make-definition-context))
 (syntax-local-bind-syntaxes (list id0) #false ctx)
 (internal-definition-context-seal ctx)
 (internal-definition-context-apply ctx id0)))
 (provide fresh))
  
   ; original.rkt
   #lang racket
   (require fresh.rkt)
   (define-syntax (macro stx)
 (with-syntax {[name (fresh)]}
   #'(begin-for-syntax
   (define original (quote-syntax name))
   (provide original
   (macro)
  
   ; identical.rkt
   #lang racket
   (require original.rkt)
   (define-syntax (macro stx)
 (with-syntax {[orig original]}
   #'(begin-for-syntax
   (define identical (quote-syntax orig))
   (provide identical
   (macro)
  
   ; different.rkt
   #lang racket
   (require fresh.rkt)
   (define-syntax (macro stx)
 (with-syntax {[name (fresh)]}
   #'(begin-for-syntax
   (define different (quote-syntax name))
   (provide different
   (macro)
  
   ; check.rkt
   #lang racket
   (require fresh.rkt original.rkt identical.rkt different.rkt)
   (begin-for-syntax
 (unless (free-identifier=? original identical)
   (error 'fresh ~v != ~v\n original identical))
 (when (free-identifier=? original different)
   (error 'fresh ~v == ~v\n original different)))
  
   --
   Carl Eastlund
  
   _
 Racket Developers list:
 http://lists.racket-lang.org/dev
  
 
 


_
  Racket Developers list:
  http

Re: [racket-dev] proposal for moving to packages: repository

2013-05-23 Thread Carl Eastlund
On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay e...@barzilay.org wrote:

 9 hours ago, Carl Eastlund wrote:
  I was going to comment on the same thing.  While a naive use of git
  filter-branch might not retain the history, it should be entirely
  possible to do something a little more intelligent and keep that
  history.

 Just to be clear, this is exactly what you can't get with
 filter-branch.

  Essentially each of the new repositories could keep the entire
  history of the original repository, followed by a massive
  move/rename, then moving forward with an individual package.

 This can work, but it is unrelated to filter-branch: it's basically
 starting each package repository from a clone of the monolithic repo,
 then move  shuffle things around.

 This seems wrong to me in all kinds of ways -- but if someone wants to
 do this with *their* package (ie, not a package that I need to deal
 with), then it's certainly an option.


It doesn't seem wrong to me.  It's an accurate representation of the
history of the project, which is exactly what git is for retaining.  Where
does the problem come from?  If git filter-branch doesn't maintain the
history we need, it's not the right tool for the job.

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


Re: [racket-dev] proposal for moving to packages: repository

2013-05-23 Thread Carl Eastlund
On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay e...@barzilay.org wrote:

 A few minutes ago, Carl Eastlund wrote:
  On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay e...@barzilay.org wrote:
 
  9 hours ago, Carl Eastlund wrote:
   I was going to comment on the same thing.  While a naive use
   of git filter-branch might not retain the history, it should
   be entirely possible to do something a little more intelligent
   and keep that history.
 
  Just to be clear, this is exactly what you can't get with
  filter-branch.
 
   Essentially each of the new repositories could keep the entire
   history of the original repository, followed by a massive
   move/rename, then moving forward with an individual package.
 
  This can work, but it is unrelated to filter-branch: it's
  basically starting each package repository from a clone of the
  monolithic repo, then move  shuffle things around.
 
  This seems wrong to me in all kinds of ways -- but if someone
  wants to do this with *their* package (ie, not a package that I
  need to deal with), then it's certainly an option.
 
  It doesn't seem wrong to me.  It's an accurate representation of the
  history of the project, which is exactly what git is for retaining.
  Where does the problem come from?

 The problem of filter-branch?  It has no problems, it does exactly
 what it is supposed to do.


It has no problems?  Where above you stated this is exactly what you
can't get with filter-branch in reference to keeping our packages'
relevant history.  That sounds like a problem to me, in our current context.

But filter-branch is not what I was talking about.  I was talking about
_not_ using filter-branch, and instead doing something that does keep
history.


   If git filter-branch doesn't maintain the history we need, it's not
  the right tool for the job.

 If the drracket files are irrelevant for the swindle package then they
 shouldn't be in the swindle repository -- and on the exact same token,
 the development history of drracket shouldn't be there either.

 (This is not new, BTW, I think that there was general concensus right
 from the start of the package talk that the monolithic repo is just a
 host for a bunch of separate projects.)


Okay, then let's purge the history of irrelevant files, but keep the
history of relevant files even if they weren't in the right directory.
If the monolithic repo is just a host for a bunch of separate projects,
shouldn't it be possible to tease out their more-or-less separate histories?

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


Re: [racket-dev] proposal for moving to packages: repository

2013-05-23 Thread Carl Eastlund
On Thu, May 23, 2013 at 7:09 AM, Eli Barzilay e...@barzilay.org wrote:

 Just now, Carl Eastlund wrote:
  On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay e...@barzilay.org wrote:
 
  A few minutes ago, Carl Eastlund wrote:
  
   It doesn't seem wrong to me.  It's an accurate representation
   of the history of the project, which is exactly what git is
   for retaining.   Where does the problem come from?
 
  The problem of filter-branch?  It has no problems, it does
  exactly what it is supposed to do.
 
  It has no problems?  Where above you stated this is exactly what
  you can't get with filter-branch in reference to keeping our
  packages' relevant history.

 Relevant history is vague.  The thing that you can't do with
 filter-branch is keep the complete history if you remove files from
 the history -- the files that are gone go with their history.


  But filter-branch is not what I was talking about.  I was talking
  about _not_ using filter-branch, and instead doing something that
  does keep history.

 Like I said: what you're suggesting means keeping the full monolithic
 history of developement in the main repo, including all of the
 irrelevant files (which will be removed in the tip, but included in
 the repo).

   If git filter-branch doesn't maintain the history we need, it's not
   the right tool for the job.
 
  If the drracket files are irrelevant for the swindle package then
 they
  shouldn't be in the swindle repository -- and on the exact same
 token,
  the development history of drracket shouldn't be there either.
 
  (This is not new, BTW, I think that there was general concensus right
  from the start of the package talk that the monolithic repo is just a
  host for a bunch of separate projects.)
 
  Okay, then let's purge the history of irrelevant files, but keep the
  history of relevant files even if they weren't in the right
  directory.  If the monolithic repo is just a host for a bunch of
  separate projects, shouldn't it be possible to tease out their
  more-or-less separate histories?

 (*sigh*; please read the other email, where I went over this
 thoroughly.)


I just went over all your emails on this topic, and I can't find a single
one where you addressed this specific proposal at all.  I don't know which
one of us is misunderstanding another on this point.

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


Re: [racket-dev] Constructing an identifier to an unexported binding

2013-05-23 Thread Carl Eastlund
On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen matth...@ccs.neu.eduwrote:


 On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
 wrote:

  2. Is it possible that we could solve the problem via a
 bootstrapping-only violation of our policy that you can add types to Racket
 w/o modifying existing modules?
 
  No. We can't specify types inside `racket/base` without making
 `racket/base` depend on Typed Racket.


 1. I was proposing a fundamental change to the language, with an eye
 toward Racket 2.

 2. I was also proposing an experiment that temporarily creates such a
 dependency and we can then look for a refactoring that breaks the
 dependency again but in a way that supports the proper access to these base
 identifiers.


It shouldn't be necessary to specify types inside racket/base; it's only
necessary to make the identifiers available somehow.  Then TR can do the
type specification, but without using namespaces.  Protecting the exported
identifiers from misuse could be done by convention -- naming them
unsafe-foo or exporting them from a submodule named private -- or by
enforcement -- for instance, rather than providing them, instead exporting
a phase 1 syntax object that contains them with appropriate syntax taints /
dye packs so that they can be used for free-identifier=? but not put into
expanded code.

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


Re: [racket-dev] Constructing an identifier to an unexported binding

2013-05-23 Thread Carl Eastlund
On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:

 On 05/23/2013 01:57 AM, Eric Dobson wrote:

 Some modules have macros which expand into identifiers that are not
 exported, as they want to protect those bindings. TR currently has the
 following code which allows it to generate an identifier which is
 free-identifier=? to what would appear in the output of the macros.

 define (make-template-identifier what where)
(let ([name (module-path-index-resolve (module-path-index-join where
 #f))])
  (parameterize ([current-namespace (make-empty-namespace)])
(namespace-attach-module (current-namespace) ''#%kernel)
(parameterize ([current-module-declare-name name])
  (eval `(,#'module any '#%kernel
   (#%provide ,what)
   (define-values (,what) #f
(namespace-require `(for-template ,name))
(namespace-syntax-introduce (datum-syntax #f what)

 This turns out to be a slightly slow part of the initialization of TR.
 Does anyone know another way to get such an identifier?


 There's another way around this issue, which is to avoid creating these
 identifiers at all. In other words, change the representation of the type
 environment to something that supports symbol+module pairs as keys in
 addition to identifiers. The easiest way to do that is to add in a hash
 table behind the current free-id-table, since the two tables would handle
 disjoint sets of identifiers.

 Ryan


I would not have thought that'd work, but apparently identifier-binding
will give one that information.  Nice going, Ryan!

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


Re: [racket-dev] Constructing an identifier to an unexported binding

2013-05-23 Thread Carl Eastlund
Essentially yes.  It doesn't do anything else, but it needs an identifier
to do it.  Currently, TR starts with a module and a symbol, goes through an
expensive process to forge an identifier from them, just to call
free-identifier=? to compare based on the module and the symbol after all.
Doing the comparison directly, without ever forging the identifier, would
be quicker.

On Thu, May 23, 2013 at 8:43 PM, Eric Dobson eric.n.dob...@gmail.comwrote:

 Isn't that exactly what free-indentifier=? is checking for on
 identfiers with a module level binding? Or is there something else it
 does?

 On Thu, May 23, 2013 at 3:13 PM, Carl Eastlund c...@ccs.neu.edu wrote:
  On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper ry...@ccs.neu.edu
 wrote:
 
  On 05/23/2013 01:57 AM, Eric Dobson wrote:
 
  Some modules have macros which expand into identifiers that are not
  exported, as they want to protect those bindings. TR currently has the
  following code which allows it to generate an identifier which is
  free-identifier=? to what would appear in the output of the macros.
 
  define (make-template-identifier what where)
 (let ([name (module-path-index-resolve (module-path-index-join where
  #f))])
   (parameterize ([current-namespace (make-empty-namespace)])
 (namespace-attach-module (current-namespace) ''#%kernel)
 (parameterize ([current-module-declare-name name])
   (eval `(,#'module any '#%kernel
(#%provide ,what)
(define-values (,what) #f
 (namespace-require `(for-template ,name))
 (namespace-syntax-introduce (datum-syntax #f what)
 
  This turns out to be a slightly slow part of the initialization of TR.
  Does anyone know another way to get such an identifier?
 
 
  There's another way around this issue, which is to avoid creating these
  identifiers at all. In other words, change the representation of the
 type
  environment to something that supports symbol+module pairs as keys in
  addition to identifiers. The easiest way to do that is to add in a hash
  table behind the current free-id-table, since the two tables would
 handle
  disjoint sets of identifiers.
 
  Ryan
 
 
  I would not have thought that'd work, but apparently identifier-binding
 will
  give one that information.  Nice going, Ryan!
 
  --Carl


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


Re: [racket-dev] proposal for moving to packages: repository

2013-05-22 Thread Carl Eastlund
On Wed, May 22, 2013 at 8:21 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 At Wed, 22 May 2013 14:50:41 -0400, Eli Barzilay wrote:
  That's true, but the downside of changing the structure and having
  files and directories move post structure change will completely
  destroy the relevant edit history of the files, since it will not be
  carried over to the repos once it's split.

 It's possible that we're talking past each other due to me not getting
 this point.

 Why is it not possible to carry over history?

 The history I want corresponds to `git log --follow' on each of the
 files that end up in a repository. I'm pretty sure that such a history
 of commits can be generated for any given set of files, even if no
 ready-made tool exists already (i.e., 'git' is plenty flexible that I
 can script it myself).

 Or maybe I'm missing some larger reason?


I was going to comment on the same thing.  While a naive use of git
filter-branch might not retain the history, it should be entirely possible
to do something a little more intelligent and keep that history.
Essentially each of the new repositories could keep the entire history of
the original repository, followed by a massive move/rename, then moving
forward with an individual package.

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


Re: [racket-dev] proposal for moving to packages

2013-05-21 Thread Carl Eastlund
On Mon, May 20, 2013 at 11:20 PM, Juan Francisco Cantero Hurtado 
i...@juanfra.info wrote:

 On 05/20/13 23:24, Carl Eastlund wrote:

 On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa as...@ccs.neu.edu
 wrote:

  On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:

 Eventually, when the dust settles, I think we'll want to convert every
 directory to its own git repo, and then we can incorporate the
 individual repos as git submodules.


 One nice thing about the current repo organization is that push
 notifications for every part of the PLT codebase go to all of the
 developers.

 Will that still be available in this organization scheme? (I don't care
 if it's opt-in too much, but opt-out will hopefully mean more eyes see
 the code)

 Cheers,
 Asumu


 Overall, I'm really glad to see Racket moving into the package system.  I
 think it will be good for both (the Racket core and the package system).
 I'd like to mention, though, that git submodules can be a real pain for
 synchronizing development of multiple repositories.  They seem to have
 been
 designed primarily for importing upstream repositories, rather than for
 multiple peer repositories.  I'm not much more fond of the alternatives
 I
 have tried, either; if we're committing to splitting Racket into multiple
 repositories as well as multiple packages, we should be aware there may be
 another minor git learning curve ahead.

 Thanks to Jay and Matthew for working on all of this!


 I also think that git submodules are a bad idea for packages. One git repo
 per package is more simple and less problematic.

 Thanks for the hard work :)


Git submodules imply one repo per package.  A submodule is a mechanism that
imports external repos into a checkout of a client repo, and records the
specific commit of the checkout so that there is a correlation of the
commits in each repo stored with the client.  If we're going to use
multiple repositories, we definitely need something like submodules in
order to retain a shared commit history.

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


Re: [racket-dev] proposal for moving to packages

2013-05-20 Thread Carl Eastlund
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa as...@ccs.neu.edu wrote:

 On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
  Eventually, when the dust settles, I think we'll want to convert every
  directory to its own git repo, and then we can incorporate the
  individual repos as git submodules.

 One nice thing about the current repo organization is that push
 notifications for every part of the PLT codebase go to all of the
 developers.

 Will that still be available in this organization scheme? (I don't care
 if it's opt-in too much, but opt-out will hopefully mean more eyes see
 the code)

 Cheers,
 Asumu


Overall, I'm really glad to see Racket moving into the package system.  I
think it will be good for both (the Racket core and the package system).
I'd like to mention, though, that git submodules can be a real pain for
synchronizing development of multiple repositories.  They seem to have been
designed primarily for importing upstream repositories, rather than for
multiple peer repositories.  I'm not much more fond of the alternatives I
have tried, either; if we're committing to splitting Racket into multiple
repositories as well as multiple packages, we should be aware there may be
another minor git learning curve ahead.

Thanks to Jay and Matthew for working on all of this!

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


Re: [racket-dev] set!-transformers and syntax-local-value/immediate

2013-05-17 Thread Carl Eastlund
Asumu,

Your lookup macro's output just tells whether there is a rename somewhere
between the binding for f and its original source binding.  Rename
transformers get injected all over the place.  To get the real story, turn
your lookup macro into a loop that chases the binding back to the source.
Or, use the macro stepper with hiding off.  The let-syntax expression
expands into:

(letrec-syntaxes+values (((f1) (make-set!-transformer values))) ()
  (letrec-syntaxes+values (((f) (values (make-rename-transformer
(quote-syntax f1) ()
(lookup f)))

That's where the rename comes from.

Carl Eastlund

On Fri, May 17, 2013 at 7:30 PM, Asumu Takikawa as...@ccs.neu.edu wrote:

 Hi all,

 I'm confused about an aspect of set! and rename transformers. I'll
 explain with this example:

   #lang racket

   ;; a macro that uses `syntax-local-value/immediate`
   (define-syntax (lookup stx)
 (syntax-case stx ()
   [(_ id)
(let-values ([(f _) (syntax-local-value/immediate #'id)])
  (displayln (rename-transformer? f))
  (displayln (set!-transformer? f))
  #'0)]))

   ;; f is a set!-transformer
   (let-syntax ([f (make-set!-transformer values)])
 (lookup f))

   ;; sanity check
   (rename-transformer? (make-set!-transformer values))

 In this example, `f` is bound to a set!-transformer. The macro `lookup`
 will look up the value bound to `f` at compile-time, and I expected that
 the result would be the set! transformer.

 However, it seems like the set! transformer is somehow being turned into
 a rename transformer (note the two print statements produce #t and #f
 respectively). The last line suggests that set! transformers are not
 actually a subtype of rename transformers though.

 Am I confused about set! transformers or is there a bug here?

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


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


Re: [racket-dev] Pre-Release Checklist for v5.3.4, Second Call

2013-04-24 Thread Carl Eastlund
On Mon, Apr 22, 2013 at 11:29 PM, Ryan Culpepper ry...@ccs.neu.edu wrote

 * Carl Eastlund c...@ccs.neu.edu
   - Dracula Tests (confirm that Dracula runs from PLaneT)


Done.

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


Re: [racket-dev] [plt] Push #26536: master branch updated

2013-04-11 Thread Carl Eastlund
If we want people to be able to create higher-order functions with precise
arities via procedure-reduce-arity, for instance, we need to provide tools
for manipulating arity values.  Manipulating them is also useful for
producing error messages that describe the arity of procedure values.  I
don't see any reason to close this stuff off, when it's the one useful,
non-opaque aspect of procedure values.

Carl Eastlund


On Thu, Apr 11, 2013 at 11:13 AM, Eli Barzilay e...@barzilay.org wrote:

 Is there a real need to make this whole thing a public interface?  I'd
 think that a general direction is to move away from making it public
 (ie, remove the ability to create an arity value), and this seems to
 add a pretty big chunk of stuff in the opposite direction.


 About two weeks ago, c...@racket-lang.org wrote:
  cce has updated `master' from 6e40caa7e2 to df00bbb194.
http://git.racket-lang.org/plt/6e40caa7e2..df00bbb194
 
  =[ 7 Commits ]==
  Directory summary:
21.0% collects/racket/private/
21.5% collects/racket/
26.4% collects/scribblings/reference/
30.9% collects/tests/racket/
 
  ~~
 
  59b1e32 Carl Eastlund c...@racket-lang.org 2013-03-30 11:45
  :
  | Changed normalize-arity to coalesce arity-at-least with adjacent
 numbers.
  |
  | For instance, (normalize-arity (list 1 (arity-at-least 2))) now
 produces
  | (arity-at-least 1).  The implementation and the tests for
 normalize-arity both
  | reflect this change.  The randomized tests now also check that the
 output
  | represents the same arity as the input.
  :
M collects/racket/private/norm-arity.rkt |  82 +-
M collects/tests/racket/basic.rktl   | 112
 +-
 
  ~~
 
  e356c66 Carl Eastlund c...@racket-lang.org 2013-03-30 11:49
  :
  | Re-provide normalize-arity from racket/function.
  :
M collects/racket/function.rkt | 4 ++--
 
  ~~
 
  4dd011a Carl Eastlund c...@racket-lang.org 2013-03-30 15:49
  :
  | Added documentation for normalize-arity.
  :
M collects/scribblings/reference/procedures.scrbl | 42
 ++
 
  ~~
 
  636f8a9 Carl Eastlund c...@racket-lang.org 2013-03-30 21:04
  :
  | Moved normalized-arity?, arity=?, and arity-includes? into
 racket/function.
  :
M collects/racket/function.rkt | 94
 +++-
M collects/tests/racket/basic.rktl | 96
 +
 
  ~~
 
  aaa99d5 Carl Eastlund c...@racket-lang.org 2013-03-30 21:05
  :
  | Documented normalized-arity?, arity=?, and arity-includes?.
  :
M collects/scribblings/reference/procedures.scrbl | 87
 +++---
 
  ~~
 
  f509420 Carl Eastlund c...@racket-lang.org 2013-03-30 17:12
  :
  | Removed unnecessary duplication of normalize-arity.
  :
M collects/tests/racket/fixnum.rktl | 21 ++---
 
  ~~
 
  df00bbb Carl Eastlund c...@racket-lang.org 2013-03-31 10:34
  :
  | Updated contracts for arity-related functions.
  |
  | Added contract checking to arity=?, arity-includes?, and
 normalized-arity.
  | Removed contract checking from normalize-arity to make it a total
 predicate.
  | Updated documentation for normalize-arity to reflect this change.
  :
M collects/racket/function.rkt| 21
 -
M collects/racket/private/norm-arity.rkt  |  2 ++
M collects/scribblings/reference/procedures.scrbl | 13 ++---

 --
   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
 http://barzilay.org/   Maze is Life!


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


Re: [racket-dev] [plt] Push #26536: master branch updated

2013-04-11 Thread Carl Eastlund
If you're writing a higher-order tool like curry or negate, and want to
produce a meaningful arity for its result, you're going to need some
explicit representation of arity to manipulate, e.g. subtract one from
every number in the list after partially applying to a single argument.
Once users are manipulating the value, you either need to accept
non-normalized inputs, or you need an abstract datatype to encapsulate the
whole thing that enforces normalization.  Since we already have list-based
arities in our interfaces, I continued with the interface as it was.  I did
think of combining the two arity-includes? functions, I wasn't sure whether
the extra overloading would make things clearer or more confused.  I can
see doing it either way.

Carl Eastlund


On Thu, Apr 11, 2013 at 11:33 AM, Eli Barzilay e...@barzilay.org wrote:

 OK, that's a valid use case -- but isn't it better for both of these
 uses to just use some combinator for arities that generates a properly
 normalized arity instead of constructing lists and explicitly
 normalizing them?

 It's just that the interface looks very complex now.  Some obvious
 things:

 * `procedure-arity-includes?' vs `arity-includes?'
   (but it's the second that compares two procedures...  I'd just make
   the first accept a procedure to avoid this unfortunate naming.)

 * `normalize-arity', `normalized-arity?', `arity=?'
   (go away with a combinator, the last one gets replaced with
   `equal?')



 A few minutes ago, Carl Eastlund wrote:
  If we want people to be able to create higher-order functions with
  precise arities via procedure-reduce-arity, for instance, we need to
  provide tools for manipulating arity values.  Manipulating them is
  also useful for producing error messages that describe the arity of
  procedure values.  I don't see any reason to close this stuff off,
  when it's the one useful, non-opaque aspect of procedure values.
 
  Carl Eastlund
 
  On Thu, Apr 11, 2013 at 11:13 AM, Eli Barzilay e...@barzilay.org wrote:
 
  Is there a real need to make this whole thing a public interface?
  I'd
  think that a general direction is to move away from making it public
  (ie, remove the ability to create an arity value), and this seems to
  add a pretty big chunk of stuff in the opposite direction.
 
  About two weeks ago, c...@racket-lang.org wrote:
   cce has updated `master' from 6e40caa7e2 to df00bbb194.
 http://git.racket-lang.org/plt/6e40caa7e2..df00bbb194
  
   =[ 7 Commits
 ]==
   Directory summary:
 21.0% collects/racket/private/
 21.5% collects/racket/
 26.4% collects/scribblings/reference/
 30.9% collects/tests/racket/
  
   ~~
  
   59b1e32 Carl Eastlund c...@racket-lang.org 2013-03-30 11:45
   :
   | Changed normalize-arity to coalesce arity-at-least with adjacent
  numbers.
   |
   | For instance, (normalize-arity (list 1 (arity-at-least 2))) now
  produces
   | (arity-at-least 1).  The implementation and the tests for
  normalize-arity both
   | reflect this change.  The randomized tests now also check that
 the
  output
   | represents the same arity as the input.
   :
 M collects/racket/private/norm-arity.rkt |  82
 +-
 M collects/tests/racket/basic.rktl   | 112
  +-
  
   ~~
  
   e356c66 Carl Eastlund c...@racket-lang.org 2013-03-30 11:49
   :
   | Re-provide normalize-arity from racket/function.
   :
 M collects/racket/function.rkt | 4 ++--
  
   ~~
  
   4dd011a Carl Eastlund c...@racket-lang.org 2013-03-30 15:49
   :
   | Added documentation for normalize-arity.
   :
 M collects/scribblings/reference/procedures.scrbl | 42
  ++
  
   ~~
  
   636f8a9 Carl Eastlund c...@racket-lang.org 2013-03-30 21:04
   :
   | Moved normalized-arity?, arity=?, and arity-includes? into
 racket/
  function.
   :
 M collects/racket/function.rkt | 94
  +++-
 M collects/tests/racket/basic.rktl | 96
  +
  
   ~~
  
   aaa99d5 Carl Eastlund c...@racket-lang.org 2013-03-30 21:05
   :
   | Documented normalized-arity?, arity=?, and arity-includes?.
   :
 M collects/scribblings/reference/procedures.scrbl | 87
  +++---
  
   ~~
  
   f509420 Carl Eastlund c...@racket-lang.org 2013-03-30 17:12
   :
   | Removed unnecessary duplication of normalize-arity.
   :
 M collects/tests/racket/fixnum.rktl | 21 ++---
  
   ~~
  
   df00bbb Carl Eastlund c...@racket-lang.org 2013-03-31 10:34

[racket-dev] Cross-phase persistent modules

2013-04-05 Thread Carl Eastlund
These seem great.  I'd like to build a macro that defines cross-phase
persistent structures, so that I can make structs that can be quoted in
syntax reliably.  For that, I'd like a little more built-in support.
(Ultimately, if struct from racket/base supported a
#:cross-phase-persistent option that automatically defined a submodule,
that would be perfect---but whoever implements a tool like that is going to
need or at least want extra support, too.)

Most importantly, as far as I can tell, cross-phase persistent modules are
currently an internal silent heuristic for turning modules into persistent
ones.  I'd really like a way to explicitly declare that I want a module to
be persistent across phases.  This mechanism should report an error if the
module cannot be made persistent.  Right now, I just have to guess and
hope.  I can write my own mechanism that checks the documented structure
against my fully-expanded module, but if I get something wrong or the
documentation is wrong, my error-reporting mechanism might not line up with
reality.

Secondly, the criteria for a persistent module is a bit idiosyncratic.  For
instance, top-level constants (those defined outside of function bodies)
can be constructed by quoting numbers, booleans, symbols, strings, and byte
strings, and by using the functions cons and list.  I don't know why a
persistent module cannot quote a character, regular expression, empty list,
immutable cons, immutable vector, immutable box, immutable hash table, or
immutable prefab structure.  Oh, and going down the Datatypes reference, I
forgot keywords.  If we're special casing both cons and list, personally I
would at least add list*, and possibly more of the tools allowed in
setup/infotab (reverse, append, car, cdr), and possibly all the basic
constructors and possibly selectors for our primitive, immutable
datatypes.  If we don't want to allow these things for some reason, I'd
argue that even cons and list might not be necessary and we could restrict
the whole thing to just quote.

Thirdly, one of the nice things about dealing with syntax objects is how
datum-syntax and syntax-datum permeate the values they encounter --
lists, vectors, prefab structs, etc.  Is it possible to do the same with
transparent structs if they are defined in cross-phase persistent modules?
Is there any way to detect that?  If so, it would make adding new kinds of
syntax values a lot nicer.  Or maybe if we had a prop:syntax / gen:syntax
that supported to-syntax and to-datum operations, so we could implement our
own syntax-permeable structs?  This isn't directly related to cross-phase
persistent modules, but their existence makes this feature more desirable
than it has been previously.

Thanks to anyone [especially if your name is Matthew Flatt] who can give
this all a look!

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


Re: [racket-dev] Cross-phase persistent modules

2013-04-05 Thread Carl Eastlund
On further inspection, it looks like the grammar for cross-phase persistent
modules is not clear about where cross-expr is required and where more
general exprs are allowed.  The define-values form requires cross-expr,
which makes sense.  The #%plain-lambda and case-lambda forms appear to
permit general expressions, which also makes sense -- since cross-phase
persistent modules can't run these procedures, they might as well be able
to do whatever they want.  But the arguments of cons, list,
make-struct-type, and make-struct-type-property are documented as expr
rather than cross-expr, and that doesn't make a lot of sense.  Presumably
these should be restricted to cross-expr as well.

Carl Eastlund


On Fri, Apr 5, 2013 at 7:31 AM, Carl Eastlund c...@ccs.neu.edu wrote:

 These seem great.  I'd like to build a macro that defines cross-phase
 persistent structures, so that I can make structs that can be quoted in
 syntax reliably.  For that, I'd like a little more built-in support.
 (Ultimately, if struct from racket/base supported a
 #:cross-phase-persistent option that automatically defined a submodule,
 that would be perfect---but whoever implements a tool like that is going to
 need or at least want extra support, too.)

 Most importantly, as far as I can tell, cross-phase persistent modules are
 currently an internal silent heuristic for turning modules into persistent
 ones.  I'd really like a way to explicitly declare that I want a module to
 be persistent across phases.  This mechanism should report an error if the
 module cannot be made persistent.  Right now, I just have to guess and
 hope.  I can write my own mechanism that checks the documented structure
 against my fully-expanded module, but if I get something wrong or the
 documentation is wrong, my error-reporting mechanism might not line up with
 reality.

 Secondly, the criteria for a persistent module is a bit idiosyncratic.
 For instance, top-level constants (those defined outside of function
 bodies) can be constructed by quoting numbers, booleans, symbols, strings,
 and byte strings, and by using the functions cons and list.  I don't know
 why a persistent module cannot quote a character, regular expression, empty
 list, immutable cons, immutable vector, immutable box, immutable hash
 table, or immutable prefab structure.  Oh, and going down the Datatypes
 reference, I forgot keywords.  If we're special casing both cons and list,
 personally I would at least add list*, and possibly more of the tools
 allowed in setup/infotab (reverse, append, car, cdr), and possibly all the
 basic constructors and possibly selectors for our primitive, immutable
 datatypes.  If we don't want to allow these things for some reason, I'd
 argue that even cons and list might not be necessary and we could restrict
 the whole thing to just quote.

 Thirdly, one of the nice things about dealing with syntax objects is how
 datum-syntax and syntax-datum permeate the values they encounter --
 lists, vectors, prefab structs, etc.  Is it possible to do the same with
 transparent structs if they are defined in cross-phase persistent modules?
 Is there any way to detect that?  If so, it would make adding new kinds of
 syntax values a lot nicer.  Or maybe if we had a prop:syntax / gen:syntax
 that supported to-syntax and to-datum operations, so we could implement our
 own syntax-permeable structs?  This isn't directly related to cross-phase
 persistent modules, but their existence makes this feature more desirable
 than it has been previously.

 Thanks to anyone [especially if your name is Matthew Flatt] who can give
 this all a look!

 Carl Eastlund

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


Re: [racket-dev] [plt] Push #26372: master branch updated

2013-02-27 Thread Carl Eastlund
First of all, thanks very much, Matthew, for implementing this!  This looks
like a great feature to me.  I have often been frustrated that users' data
structures aren't easy to quote or to manipulate in macros in the same way
as pairs or vectors; this should go a long way to improving the situation.

Second, for a name, how about some variation of phase-global or
cross-phase?

An amusing but probably not too informative name: one-phase-fits-all.  ;)

Carl Eastlund

On Wed, Feb 27, 2013 at 4:58 AM, Norman Gray nor...@astro.gla.ac.uk wrote:


 Greetings.

 On 2013 Feb 27, at 01:14, Matthew Flatt mfl...@cs.utah.edu wrote:

  I think part of the problem is distinguishing module declarations
  (which don't have a phase) from module instantiations (which are
  normally phase-specific).

 If 'which don't have a phase' is the key phrase, how about:

 phase-neutral
 phase-independent
 unphased
 phase-exempt

 'phase-invariant' prompts (to me) the question '...under what
 transformation?'; 'phase-independent', like 'phase-neutral', in contrast
 suggests that the phase isn't relevant to them.

 Norman


 
  I want an adjective for a declaration that describes a treatment of its
  instances. Phaseless is bad, because no module declaration has a
  phase, but all-phase has the same problem.
 
  Phase-invariant could work, although that sounds like a property that
  module declarations might have even if they're not treated specially.
 
  How about phase-collapsing? That suggests more (to me) that something
  special is happening.
 
  At Tue, 26 Feb 2013 17:53:14 -0500, Ray Racine wrote:
  all-phase modules
  static modules
  static-phase modules
  phase-invariant modules
 
 
 
 
  On Tue, Feb 26, 2013 at 5:31 PM, Vincent St-Amour stamo...@ccs.neu.edu
 wrote:
 
  At Tue, 26 Feb 2013 16:59:01 -0500,
  mfl...@racket-lang.org wrote:
  899a327 Matthew Flatt mfl...@racket-lang.org 2013-02-26 14:14
  :
  | add experimental support for phaseless modules
  |
 
  After reading the docs, I find the name phaseless confusing. IIUC,
  these modules are not special because they have no phase, but rather
  because they're the same at all phases.
 
  Would pan-phase, omni-phase or cross-phase be an accurate
  description?
 
  Vincent
  _
   Racket Developers list:
   http://lists.racket-lang.org/dev
 
  _
   Racket Developers list:
   http://lists.racket-lang.org/dev

 --
 Norman Gray  :  http://nxg.me.uk
 SUPA School of Physics and Astronomy, University of Glasgow, UK


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

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


[racket-dev] http vs https urls for pnr.racket-lang.org

2013-01-24 Thread Carl Eastlund
If I go to pnr.racket-lang.org, I get a page that says:

  It works!
  This is the default web page for this server.
  The web server software is running but no content has been added, yet.

If I manually add https://; to the front, I get to the page I wanted with
a list of all the packages.  We should make the http:// version
automatically redirect to the https:// version.  The current behavior is
very confusing.

Sorry for any redundancy if this is already on a todo list for the release
somewhere.

Carl Eastlund

P.S. Sorry for any redundancy if this is already on a todo list for the
release somewhere.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] http vs https urls for pnr.racket-lang.org

2013-01-24 Thread Carl Eastlund
I maintain that I went to the right website, you just didn't know it yet.
;-)

Carl Eastlund


On Thu, Jan 24, 2013 at 12:44 PM, Jay McCarthy jay.mccar...@gmail.comwrote:

 Yes, someone else reported that when they go to a different website
 than the PNR they don't get to the PNR. I have it on my list to add a
 redirect but haven't got to it just yet.

 Jay

 On Thu, Jan 24, 2013 at 10:06 AM, Carl Eastlund c...@ccs.neu.edu wrote:
  If I go to pnr.racket-lang.org, I get a page that says:
 
It works!
This is the default web page for this server.
The web server software is running but no content has been added, yet.
 
  If I manually add https://; to the front, I get to the page I wanted
 with a
  list of all the packages.  We should make the http:// version
 automatically
  redirect to the https:// version.  The current behavior is very
 confusing.
 
  Sorry for any redundancy if this is already on a todo list for the
 release
  somewhere.
 
  Carl Eastlund
 
  P.S. Sorry for any redundancy if this is already on a todo list for the
  release somewhere.
 
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 



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

 The glory of God is Intelligence - DC 93


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


Re: [racket-dev] Pre-Release Checklist for v5.3.2

2013-01-19 Thread Carl Eastlund
On Thu, Jan 17, 2013 at 1:46 PM, Ryan Culpepper ry...@ccs.neu.edu wrote:

 * Carl Eastlund c...@ccs.neu.edu
   - Dracula Tests (confirm that Dracula runs from PLaneT)


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


Re: [racket-dev] Attempted clarification for planet2 docs

2013-01-02 Thread Carl Eastlund
There _is_ reason to think these modules are different, because they were
different in Planet1.  I've had to remind myself several times that Planet2
packages don't have special require forms, and that's just during
discussions -- I haven't even been writing code with them yet.  Clarifying
that Planet2 simplifies the require lines, and makes user packages on a
peer level with built-in collections, is a useful thing to put early on in
the Planet2 docs.

Carl Eastlund


On Wed, Jan 2, 2013 at 3:27 PM, Jay McCarthy jay.mccar...@gmail.com wrote:

 The documentation already says A package is a set of modules for some
 number of collections. And there's no reason to think that these modules
 are different from other modules, so I don't see why we need to point out
 that they are required like all other modules are.

 If you think it's very confusing, then feel free to push the commit with
 two small changes:

 1. The docs don't use the term planet2, so just say the Racket package
 manager

 2. Consider using the same examples from the rest of the docs (such as
 data/matrix from tic-tac-toe)

 Jay



 On Wed, Jan 2, 2013 at 12:30 PM, John Clements 
 cleme...@brinckerhoff.orgwrote:

 As I was trying to assembly my first planet2 package, I found myself
 wondering how exactly to 'require' modules associated with planet2
 packages. My initial assumption (require them like any other collection
 containing modules) turned out to be correct, but there was a period when I
 doubted this, and I think it should be documented.

 Below is a proposed doc change; I'll commit it if you like it, or abandon
 it if not. I'm including the (git format-patch) text and also attaching it
 as a file.

 John



 From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
 From: John Clements cleme...@racket-lang.org
 Date: Tue, 1 Jan 2013 10:40:40 -0800
 Subject: [PATCH] added docs on requiring planet2 modules

 ---
  collects/planet2/scribblings/planet2.scrbl |   14 ++
  1 files changed, 14 insertions(+), 0 deletions(-)

 diff --git a/collects/planet2/scribblings/planet2.scrbl
 b/collects/planet2/scribblings/planet2.scrbl
 index e9e565a..81d6e58 100644
 --- a/collects/planet2/scribblings/planet2.scrbl
 +++ b/collects/planet2/scribblings/planet2.scrbl
 @@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.

  @section{Using Packages}

 +Modules installed using planet2 may be @tech{require}d like any other
 +modules. For instance, if the package @pkgname{recipes} contains
 +the module file  @filepath{vegan/fruitsalad.rkt}, then package users
 +who have this package installed may evaluate
 +
 +@racketblock[(require vegan/fruitsalad)]
 +
 +...to require this module.
 +
 +@; 
 +
 +@section{Managing Packages}
 +
 +
  The Racket package manager has two user interfaces: a command line
 @exec{raco}
  sub-command and a library. They have the exact same capabilities, as
  the command line interface invokes the library functions and
 --
 1.7.7.5 (Apple Git-26)





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

 The glory of God is Intelligence - DC 93

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


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


Re: [racket-dev] Attempted clarification for planet2 docs

2013-01-02 Thread Carl Eastlund
It doesn't need to be phrased as a comparison to Planet1, but it can be
given as a reassurance that this package system thingy does not add any
baggage to require lines.

Carl Eastlund


On Wed, Jan 2, 2013 at 3:49 PM, Jay McCarthy jay.mccar...@gmail.com wrote:

 I agree in that context that it is useful as a part of the What's
 different about Planet 2? And it's there (question 6).

 But, in the context of a new Racket user learning about packages, I don't
 see a reason to add the baggage of how it's different than some system
 they've never used.

 Jay


 On Wed, Jan 2, 2013 at 1:40 PM, Carl Eastlund c...@ccs.neu.edu wrote:

 There _is_ reason to think these modules are different, because they were
 different in Planet1.  I've had to remind myself several times that Planet2
 packages don't have special require forms, and that's just during
 discussions -- I haven't even been writing code with them yet.  Clarifying
 that Planet2 simplifies the require lines, and makes user packages on a
 peer level with built-in collections, is a useful thing to put early on in
 the Planet2 docs.

 Carl Eastlund


 On Wed, Jan 2, 2013 at 3:27 PM, Jay McCarthy jay.mccar...@gmail.comwrote:

 The documentation already says A package is a set of modules for some
 number of collections. And there's no reason to think that these modules
 are different from other modules, so I don't see why we need to point out
 that they are required like all other modules are.

 If you think it's very confusing, then feel free to push the commit with
 two small changes:

 1. The docs don't use the term planet2, so just say the Racket
 package manager

 2. Consider using the same examples from the rest of the docs (such as
 data/matrix from tic-tac-toe)

 Jay



 On Wed, Jan 2, 2013 at 12:30 PM, John Clements 
 cleme...@brinckerhoff.org wrote:

 As I was trying to assembly my first planet2 package, I found myself
 wondering how exactly to 'require' modules associated with planet2
 packages. My initial assumption (require them like any other collection
 containing modules) turned out to be correct, but there was a period when I
 doubted this, and I think it should be documented.

 Below is a proposed doc change; I'll commit it if you like it, or
 abandon it if not. I'm including the (git format-patch) text and also
 attaching it as a file.

 John



 From d3f72c47820effb240532c518378dc9709d69600 Mon Sep 17 00:00:00 2001
 From: John Clements cleme...@racket-lang.org
 Date: Tue, 1 Jan 2013 10:40:40 -0800
 Subject: [PATCH] added docs on requiring planet2 modules

 ---
  collects/planet2/scribblings/planet2.scrbl |   14 ++
  1 files changed, 14 insertions(+), 0 deletions(-)

 diff --git a/collects/planet2/scribblings/planet2.scrbl
 b/collects/planet2/scribblings/planet2.scrbl
 index e9e565a..81d6e58 100644
 --- a/collects/planet2/scribblings/planet2.scrbl
 +++ b/collects/planet2/scribblings/planet2.scrbl
 @@ -200,6 +200,20 @@ imply a change in the @tech{checksum}.

  @section{Using Packages}

 +Modules installed using planet2 may be @tech{require}d like any other
 +modules. For instance, if the package @pkgname{recipes} contains
 +the module file  @filepath{vegan/fruitsalad.rkt}, then package users
 +who have this package installed may evaluate
 +
 +@racketblock[(require vegan/fruitsalad)]
 +
 +...to require this module.
 +
 +@; 
 +
 +@section{Managing Packages}
 +
 +
  The Racket package manager has two user interfaces: a command line
 @exec{raco}
  sub-command and a library. They have the exact same capabilities, as
  the command line interface invokes the library functions and
 --
 1.7.7.5 (Apple Git-26)





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

 The glory of God is Intelligence - DC 93

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





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

 The glory of God is Intelligence - DC 93

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


[racket-dev] raco make clean

2012-12-16 Thread Carl Eastlund
How do I remove .zo files corresponding to various source files if I have
set the PLTCOMPILEDROOTS environment variable?  I can no longer just rm -r
compiled, and I don't want to destroy more than necessary by deleting the
entire PLTCOMPILEDROOTS tree.  However, if I just leave .zo files sitting
around, I can, for instance, get odd phantom modules that I can require but
show up nowhere in source.  This makes it hard to check if I am committing
valid code to a repository, for instance.  I would really like something
like raco make --clean that removes relevant .zo files for its arguments,
if it doesn't already exist.

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


Re: [racket-dev] first and rest in racket/base

2012-12-13 Thread Carl Eastlund
Throw cons? in with empty?, please.

Carl Eastlund



On Thu, Dec 13, 2012 at 2:13 PM, Asumu Takikawa as...@ccs.neu.edu wrote:

 On 2012-12-13 12:44:38 -0500, Vincent St-Amour wrote:
  Does this sound reasonable?

 +1. While we're at it, might as well also put at least `empty` and
 `empty?` in there too. These trip me up as well.

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


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


Re: [racket-dev] first and rest in racket/base

2012-12-13 Thread Carl Eastlund
If they do the wrong thing, we should fix them, not deprecate them.  We're
not LISP, let's not promote car/cdr as the primary names for list
operations.

Carl Eastlund



On Thu, Dec 13, 2012 at 2:19 PM, Eli Barzilay e...@barzilay.org wrote:

 -1, since they are different from what some people would expect them
 to do.  -2 for the `empty', `cons?' etc aliases.


 An hour and a half ago, Vincent St-Amour wrote:
  I just got tripped up, again, trying to traverse a list with `first'
  and `rest' in a `racket/base' file. `first' and `rest' are only
  available in `racket' and `racket/list', but not in `racket/base'.
 
  If we want to encourage use of `first' and `rest' over `car' and
  `cdr' and of `racket/base' when possible (which, e.g., the style
  guide does), I think it makes sense to provide `first' and `rest' in
  `racket/base'.
 
  The attached patch implements that change.
 
  Does this sound reasonable?

 --
   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
 http://barzilay.org/   Maze is Life!
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev


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


Re: [racket-dev] first and rest in racket/base

2012-12-13 Thread Carl Eastlund
Vincent's proposal wasn't let's treat car as first, his proposal was
let's export it in racket/base.  If we don't like first/rest, we should
have a proposal to remove them from #lang racket... right?  Otherwise,
let's put them in racket/base.  They're very simple names for very, very
common operations.  I use them all the time, and it makes me write
different code in racket/base than in racket when I can't get them.  I
would like to either always have them, or be convinced of why I should
never have them.

Carl Eastlund



On Thu, Dec 13, 2012 at 2:40 PM, Jay McCarthy jay.mccar...@gmail.comwrote:

 I agree with Eli. first is not car and shouldn't be treated as it.

 car : (Cons a b) - a
 first : (List a) - a

 I also agree with Carl that we should deprecate grandpa's names and
 give nice names. I suggest fst and snd and pair

 Jay

 On Thu, Dec 13, 2012 at 12:26 PM, Carl Eastlund c...@ccs.neu.edu wrote:
  If they do the wrong thing, we should fix them, not deprecate them.
  We're
  not LISP, let's not promote car/cdr as the primary names for list
  operations.
 
  Carl Eastlund
 
 
 
  On Thu, Dec 13, 2012 at 2:19 PM, Eli Barzilay e...@barzilay.org wrote:
 
  -1, since they are different from what some people would expect them
  to do.  -2 for the `empty', `cons?' etc aliases.
 
 
  An hour and a half ago, Vincent St-Amour wrote:
   I just got tripped up, again, trying to traverse a list with `first'
   and `rest' in a `racket/base' file. `first' and `rest' are only
   available in `racket' and `racket/list', but not in `racket/base'.
  
   If we want to encourage use of `first' and `rest' over `car' and
   `cdr' and of `racket/base' when possible (which, e.g., the style
   guide does), I think it makes sense to provide `first' and `rest' in
   `racket/base'.
  
   The attached patch implements that change.
  
   Does this sound reasonable?
 
  --
((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
  http://barzilay.org/   Maze is
 Life!
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
 
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 



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

 The glory of God is Intelligence - DC 93


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


[racket-dev] Planet 2 default package name services

2012-12-12 Thread Carl Eastlund
The default Planet 2 package name services are URLs based on plt-etc.byu.edu.
While I understand why Planet 2 is hosted there -- all of Racket is at one
university or another -- wouldn't a racket-lang.org URL be better, and then
redirect to *.byu.edu behind the scenes?  Like planet2.racket-lang.org for
plt-etc.byu.edu:9003 and legacy.planet2.racket-lang.org for ...:9004, or
something like that?  That would be more intuitive for anyone looking at
the URLs, and flexible in case we decide to move the hosting at a later
date.

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


Re: [racket-dev] planet2 and versions

2012-12-12 Thread Carl Eastlund
I believe it is by design that Planet 2 does not resolve this kind of
issue.  This gives us room to experiment with different solutions without
committing to one up-front, since Planet 1 ran into various limitations of
its built-in policies.

I will propose one possible solution for your webapis example.
Distribute a primary wrapper package called webapis and separate specific
versions such as webapis1, webapis2, and so forth.  Have the code in
webapis determine at compile-time which specific version of webapis is
appropriate for the current Racket version and install that package.  The
specific packages would contain the actual code a client would import.
That way, installing the webapis package on any Racket version would
install only the version of the implementation that works.

I don't know if this is a complete solution, but it seems like a reasonable
starting point.  As we figure out what patterns work, they themselves can
be developed as reusable tools and built into their own packages.  I think
this room for improvement will make Planet 2 a much better long-term model
than Planet 1.  Of course we do eventually want a default system that
package developers can use without too much mucking about with
experimental versioning systems.  But I think an initial period of
crowd-sourcing the design of that system will do us some good.

Carl Eastlund



On Wed, Dec 12, 2012 at 2:29 PM, Ryan Culpepper r...@cs.utah.edu wrote:

 I'm trying to understand how things are supposed to work in planet2
 without version information.

 Let's say I release a package, webapis. Time passes, and I notice that
 Racket gets some cool new features (eg, better SSL support) that the
 webapis package should use. I write the code, and ...

 Do I release the new code under the same package name? If so, then the
 package breaks for older versions of Racket, because IIUC planet2 has
 nothing corresponding to planet1's 'required-core-version field. And there
 doesn't seem to be a way to tell Racket no, sorry, go back to the older
 version of the package. (Rather, there's no way for a client to do so. The
 fix would be for the package maintainer to release an upgrade that
 reverts to the old code.) So it seems like it would be really bad for me to
 release the new code under the name webapis.

 In other words, if a package changes its dependencies, that's an
 incompatible change for the package, and it needs a new name. Right?

 Suppose I release the new code as webapis2. And suppose there's another
 package (let's call it scriblogify) that depends on webapis. If that
 code wants to use webapis2, that's a dependency change, so it would have
 to be released as scriblogify2. There's no way to express link me with
 the most recent compatible version of webapis*, right?

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


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


Re: [racket-dev] And/or as procedures when not in application position

2012-12-10 Thread Carl Eastlund
I don't like this idea for Racket.  The macros and and or do not behave
like functions any more than if does.  This isn't Haskell, our functions
are eager while our conditional forms are short-circuiting.  If we want
first-order values that perform conjunction and disjunction, but eagerly,
we should give them separate names.  Otherwise we're going to get some very
confusing programs.  For instance, if you treat and / or as functions,
various program transformations that seem sensible no longer hold.  For
instance,

(and #true 'result (error oh no))

is not the same as

(let {[f and]} (f #true 'result (error oh no)))

...if and produces a short-circuiting form in the former case and an
eager function in the latter.

I do agree that functions performing boolean conjunction/disjunction are
useful.  We could call these things andf / orf, and/proc / or/proc, conj /
disj, or any number of other paired names that aren't already taken for
conditional special forms.

Carl Eastlund



On Mon, Dec 10, 2012 at 6:16 PM, J. Ian Johnson i...@ccs.neu.edu wrote:

 I just made a pull request for making and/or expand to functions that
 perform and/or following a discussion with stamourv and asumu. Vincent
 believes these additions should also be made to the student languages, but
 I thought I'd start a discussion about this before doing that work.
 What are people's thoughts on this?
 -Ian
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev


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


Re: [racket-dev] Identifier macros

2012-12-05 Thread Carl Eastlund
On looking back, my confusion was not entirely due to the documentation,
but partly from my own expectations coming in to it.  If I just look up
identifier macro, trying to figure out how to write one, I get a link to
section 16.1.5.  This does not directly state the context involving
syntax-rules; it instead describes an identifier macro simply as ...works
in any expression.  The documentation then goes on to present
syntax-id-rules as a mechanism for identifier macros, presenting set!
transformation as well.  So while it doesn't explicitly state that set!
transformers and identifier macros are the same thing, it does appear to
imply it and doesn't clarify the matter.  If we're going to use identifier
macro as an indexed technical term, we should probably have a more precise
discussion of it in the reference manual as well that spells out how these
things work.  I know I wasn't the only one surprised to find out that
ordinary define-syntax  syntax-case / syntax-parse macros can expand (what
most people would call) identifier macros.  The only way I can figure this
out in the documentation is from a very close reading of the low-level
expansion model, which is not written terribly plainly to begin with.

--Carl

Carl Eastlund

On Wed, Dec 5, 2012 at 2:12 PM, Matthew Flatt mfl...@cs.utah.edu wrote:

 At Wed, 5 Dec 2012 09:41:37 -0500, Matthias Felleisen wrote:
 
  I think two additions/refinements would be good here:
 
  1. The section on identifier macros in the Guide (16.1.5) should mention
 that
  define-syntax introduces short-hands for identifiers, period.

 I think a `define-syntax' that binds to a procedure of one argument
 is what you mean --- but section 16.1 is about `syntax-rules' and
 `syntax-id-rules', not procedures as transformers.

 Improving the start of 16.2 along these lines makes sense, along with a
 better connection to 16.1. Or maybe you're suggesting a different
 organization than the current 16.1--16.2 split?

 I'm still unclear on the specific text that confused Carl, though. Was
 it 16.1?



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


[racket-dev] Planet 2 package names

2012-12-03 Thread Carl Eastlund
Currently (the latest nightly build), the names of Planet 2 packages are
restricted to use only the characters a-z, A-Z, _, and -.  The current set
of Racket collections, on the other hand, uses a-z, 0-9, and -.  Planet 1
also has several packages using 0-9.  We need to add digits to the set of
valid names if we want 2htdp, algol60, planet2 (itself!), r5rs, and r6rs to
be package-friendly.  I know if I were to release a package named after
ACL2 somehow, I'd be hard-pressed to figure out what to do with the 2.

Planet 1 packages and Racket collections also don't use A-Z (with one or
two exceptions on Planet).  In theory, we could disallow those characters
and gain compatibility with case-insensitive mediums such as the default
Mac OS X filesystem.  I'm not particularly attached to this second
proposal, but since it leads to potential errors I thought it was worth
bringing up.  If we leave both cases in, we at least need to make sure
programs that run on Windows and Unix don't break on Mac due to package
names conflicting on the filesystem.

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


Re: [racket-dev] Planet 2 package names

2012-12-03 Thread Carl Eastlund
Yay!

Carl Eastlund


On Mon, Dec 3, 2012 at 3:10 PM, Jay McCarthy jay.mccar...@gmail.com wrote:

 That's a typo in the docs. Numbers are allowed.

 Jay

 On Mon, Dec 3, 2012 at 1:03 PM, Carl Eastlund c...@ccs.neu.edu wrote:
  Currently (the latest nightly build), the names of Planet 2 packages are
  restricted to use only the characters a-z, A-Z, _, and -.  The current
 set
  of Racket collections, on the other hand, uses a-z, 0-9, and -.  Planet 1
  also has several packages using 0-9.  We need to add digits to the set of
  valid names if we want 2htdp, algol60, planet2 (itself!), r5rs, and r6rs
 to
  be package-friendly.  I know if I were to release a package named after
  ACL2 somehow, I'd be hard-pressed to figure out what to do with the 2.
 
  Planet 1 packages and Racket collections also don't use A-Z (with one or
 two
  exceptions on Planet).  In theory, we could disallow those characters and
  gain compatibility with case-insensitive mediums such as the default Mac
 OS
  X filesystem.  I'm not particularly attached to this second proposal, but
  since it leads to potential errors I thought it was worth bringing up.
  If
  we leave both cases in, we at least need to make sure programs that run
 on
  Windows and Unix don't break on Mac due to package names conflicting on
 the
  filesystem.
 
  Carl Eastlund
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 



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

 The glory of God is Intelligence - DC 93


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


  1   2   3   >