Re: [racket-dev] Can't log in to pkg.racket-lang.org
Thanks, that worked. Carl Eastlund On Mon, Jan 27, 2014 at 12:18 AM, Kazuhiro HISHINUMA wrote: > 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
[racket-dev] Can't log in to pkg.racket-lang.org
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] Pre-Release Checklist for v6.0, Second Call
On Sun, Dec 29, 2013 at 1:57 PM, Ryan Culpepper wrote: > * Carl Eastlund > - Dracula Tests (confirm that Dracula runs from PLaneT) > Done. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics updates
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" 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 > 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 > 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 > >> 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 > >> > 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 > >> >> 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" > >> >> > To: "Carl Eastlund" > >> >> > Cc: "Racket Developers" > >> >> > 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
Re: [racket-dev] [plt] Push #27511: master branch updated
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 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
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" wrote: > I changed it to (call-with-limits (* 30 60) 2048 (lambda () > )) 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" > To: "J. Ian Johnson" > Cc: "dev" > 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 have the form (lambda () )? > 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 ), 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
Does have the form (lambda () )? 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" wrote: > I'm running my analysis benchmarks in the context of (with-limits (* 30 > 60) 2048 ), 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
On Fri, Sep 6, 2013 at 2:58 PM, Stephen Chang 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 > >> > wrote: > >> >> > >> >> > "Among the bodys, besides stopping the iteration and preventing > later > >> >> > body evaluations, a #:break guard-expr or #:final guard-expr clause > >> >> > starts a > >> >> > new internal-definition context." > >> >> > >> >> I had the same thought process as Carl. I now understand the behavior > >> >> but I don't understand why it's needed? It seems kind of arbitrary > >> >> since no other form allows multiple internal def contexts in the body > >> >> like this. Is there a practical example? > >> >> > >> >> On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund > wrote: > >> >> > Okay, I see what's going on here. It's very subtle though, and > >> >> > probably > >> >> > deserves some explanation in split-for-body's documentation. > >> >> > > >> >> > My first thought on seeing my non-fix version break here is that I > >> >> > can > >> >> > make > >> >> > split-for-body break the same way. The problem is that my non-fix > >> >> > separates > >> >> > the definition of fish? from the definitions of red? and blue?, > which > >> >> > it > >> >> > depends on. I can make split-for-body separate them the same way, > by > >> >> > putting a #:break or #:final clause in between the definition of > >> >> > fish? > >> >> > and > >> >> > the begin form. > >> >> > > >> >> > The problem with doing so is a subtle point about for loops that is > >> >> > only > >> >> > mentioned in the last sentence of the last paragraph of the > >> >> > documentation of > >> >> > for itself: > >> >> > > >> >> > "Among the bodys, besides stopping the iteration and preventing > >> >> > later > >> >> > body > >> >> > evaluations, a #:break guard-expr or #:final guard-expr clause > starts > >> >> > a > >> >> > new > >> >> > internal-definition context." > >> >> > > >> >> > So that's what split-for-body is preserving, the boundaries between > >> >> > internal > >> >> > definition contexts. That's not at all what I had expected it was > >> >> > doing; I > >> >> > had no idea the body of a for loop constituted multiple such > >> >> > contexts. > >> >> > > >> >> > Anyway, thanks for the clarification, I now understand why > >> >> > abstractions > >> >> > over > >> >> > for loops need to use split-for-body. > >> >> > > >> >> > Carl Eastlund > >> >> > > >> >> > > >> >> > On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt > > >> >> > wrote: > >> >> >> > >> >> >> Sorry that I forgot to add the `let` while turning the code you > sent > >> >> >> into a full example. Here's another try. > >> >> >> > >> >> >> #lang racket/base > >> >> >> (require (for-syntax racke
Re: [racket-dev] split-for-body from syntax/for-body
You're proving that (let () ...) is necessary, which I have explicitly agreed with since the original email, but you have not yet demonstrated that split-for-body is necessary. Here is the fix I have described twice already, now explicitly put into the define-syntax-rule solution: (define-syntax-rule (for/print/fixed clauses pre .. result) (for clauses pre ... (printf "~v\n" (let () result Carl Eastlund On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt wrote: > > #lang racket/base > (require (for-syntax racket/base > syntax/parse > syntax/for-body)) > > (define-syntax (for/print/good stx) > (syntax-parse stx > [(_ clauses . body) > (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) >(syntax > (for clauses > pre ... > (printf "~v\n" (let () post ...)])) > > (define-syntax-rule (for/print/bad clauses pre ... result) > (for clauses > pre ... > (printf "~v\n" result))) > > ;; Try changing to for/print/bad: > (for/print/good ([i 1]) > (define (fish? v) (or (red? v) (blue? v))) > (begin > (define (red? v) (eq? v 'red)) > (define (blue? v) (eq? v 'blue)) > (fish? i))) > > > At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: > > Right, that's the issue with needing the (let () result) in my > > define-syntax-rule version. I still didn't need split-for-body, which > > doesn't guarantee there are no definitions in the post ... part. All it > > guarantees to eliminate are #:final and #:break. > > > > Carl Eastlund > > > > > > On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt > wrote: > > > > > The issue is `begin` splicing. The `result` form could be a `begin` > > > form that contains definitions that are referenced by a preceding > > > forms. > > > > > > For example, given > > > > > > (define (fish? v) (or (red? v) (blue? v))) > > > (begin > > > (define (red? v) ) > > > (define (blue? v) ) > > > 5) > > > > > > With `begin` splicing, that turns into > > > > > > (define (fish? v) (or (red? v) (blue? v))) > > > (define (red? v) ) > > > (define (blue? v) ) > > > 5 > > > > > > which is different than > > > > > > (define (fish? v) (or (red? v) (blue? v))) > > > (let () > > >(define (red? v) ) > > >(define (blue? v) ) > > >5) > > > > > > At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote: > > > > Is this function ever particularly necessary? Its intended use > seems to > > > be > > > > like so: > > > > > > > > (define-syntax (for/print stx) > > > > (syntax-parse stx > > > > [(_ clauses . body) > > > > (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) > > > >(syntax > > > > (for clauses > > > >pre ... > > > >(printf "~v/n" (let () post ...)])) > > > > > > > > That way any #:break or #:final from the body ends up in pre ..., > where > > > the > > > > enclosing for loop will interpret them, and post ... will only > include > > > > normal definitions and expressions. > > > > > > > > But it seems to me there's a much easier way that should always work: > > > > > > > > (define-syntax-rule (for/print clauses pre ... result) > > > > (for clauses > > > > pre ... > > > > (printf "~v\n" result))) > > > > > > > > This not only puts all #:break and #:final clauses in pre ..., it > should > > > > guarantee result is an expression. Perhaps one should still write > (let > > > () > > > > result) in case result is (begin defn expr), but that's still simpler > > > than > > > > using split-for-body. > > > > > > > > My question is -- have I overlooked some clever subtlety here that > makes > > > > split-for-body necessary, or is it usually easier to just decompose > pre > > > ... > > > > result rather than bothering with split-for-body? > > > > > > > > Carl Eastlund > > > > _ > > > > Racket Developers list: > > > > http://lists.racket-lang.org/dev > > > > > > > > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] split-for-body from syntax/for-body
Is this function ever particularly necessary? Its intended use seems to be like so: (define-syntax (for/print stx) (syntax-parse stx [(_ clauses . body) (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) (syntax (for clauses pre ... (printf "~v/n" (let () post ...)])) That way any #:break or #:final from the body ends up in pre ..., where the enclosing for loop will interpret them, and post ... will only include normal definitions and expressions. But it seems to me there's a much easier way that should always work: (define-syntax-rule (for/print clauses pre ... result) (for clauses pre ... (printf "~v\n" result))) This not only puts all #:break and #:final clauses in pre ..., it should guarantee result is an expression. Perhaps one should still write (let () result) in case result is (begin defn expr), but that's still simpler than using split-for-body. My question is -- have I overlooked some clever subtlety here that makes split-for-body necessary, or is it usually easier to just decompose pre ... result rather than bothering with split-for-body? Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
Right, that's the issue with needing the (let () result) in my define-syntax-rule version. I still didn't need split-for-body, which doesn't guarantee there are no definitions in the post ... part. All it guarantees to eliminate are #:final and #:break. Carl Eastlund On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt wrote: > The issue is `begin` splicing. The `result` form could be a `begin` > form that contains definitions that are referenced by a preceding > forms. > > For example, given > > (define (fish? v) (or (red? v) (blue? v))) > (begin > (define (red? v) ) > (define (blue? v) ) > 5) > > With `begin` splicing, that turns into > > (define (fish? v) (or (red? v) (blue? v))) > (define (red? v) ) > (define (blue? v) ) > 5 > > which is different than > > (define (fish? v) (or (red? v) (blue? v))) > (let () >(define (red? v) ) >(define (blue? v) ) >5) > > At Fri, 6 Sep 2013 11:15:50 -0400, Carl Eastlund wrote: > > Is this function ever particularly necessary? Its intended use seems to > be > > like so: > > > > (define-syntax (for/print stx) > > (syntax-parse stx > > [(_ clauses . body) > > (with-syntax ([([pre ...] [post ...]) (split-for-body #'body)]) > >(syntax > > (for clauses > >pre ... > >(printf "~v/n" (let () post ...)])) > > > > That way any #:break or #:final from the body ends up in pre ..., where > the > > enclosing for loop will interpret them, and post ... will only include > > normal definitions and expressions. > > > > But it seems to me there's a much easier way that should always work: > > > > (define-syntax-rule (for/print clauses pre ... result) > > (for clauses > > pre ... > > (printf "~v\n" result))) > > > > This not only puts all #:break and #:final clauses in pre ..., it should > > guarantee result is an expression. Perhaps one should still write (let > () > > result) in case result is (begin defn expr), but that's still simpler > than > > using split-for-body. > > > > My question is -- have I overlooked some clever subtlety here that makes > > split-for-body necessary, or is it usually easier to just decompose pre > ... > > result rather than bothering with split-for-body? > > > > Carl Eastlund > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] split-for-body from syntax/for-body
On Fri, Sep 6, 2013 at 2:43 PM, Stephen Chang wrote: > On Fri, Sep 6, 2013 at 2:36 PM, Carl Eastlund wrote: > > They have to be separate internal definition contexts in order for > #:break > > and #:final to be able to stop execution before the definitions > themselves > > get run. > > Hmm, ok. I guess my question was why does one need #:final and #:break > in the body like that? > It's useful when the condition for loop termination and the value of the loop body both depend on some derived computation from the sequence elements: (for/list ([x (in-stream S)]) (define y (f x)) #:break (g? y) (h y)) > Carl Eastlund > > > > > > On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang > wrote: > >> > >> > "Among the bodys, besides stopping the iteration and preventing later > >> > body evaluations, a #:break guard-expr or #:final guard-expr clause > starts a > >> > new internal-definition context." > >> > >> I had the same thought process as Carl. I now understand the behavior > >> but I don't understand why it's needed? It seems kind of arbitrary > >> since no other form allows multiple internal def contexts in the body > >> like this. Is there a practical example? > >> > >> On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund wrote: > >> > Okay, I see what's going on here. It's very subtle though, and > probably > >> > deserves some explanation in split-for-body's documentation. > >> > > >> > My first thought on seeing my non-fix version break here is that I can > >> > make > >> > split-for-body break the same way. The problem is that my non-fix > >> > separates > >> > the definition of fish? from the definitions of red? and blue?, which > it > >> > depends on. I can make split-for-body separate them the same way, by > >> > putting a #:break or #:final clause in between the definition of fish? > >> > and > >> > the begin form. > >> > > >> > The problem with doing so is a subtle point about for loops that is > only > >> > mentioned in the last sentence of the last paragraph of the > >> > documentation of > >> > for itself: > >> > > >> > "Among the bodys, besides stopping the iteration and preventing > later > >> > body > >> > evaluations, a #:break guard-expr or #:final guard-expr clause starts > a > >> > new > >> > internal-definition context." > >> > > >> > So that's what split-for-body is preserving, the boundaries between > >> > internal > >> > definition contexts. That's not at all what I had expected it was > >> > doing; I > >> > had no idea the body of a for loop constituted multiple such contexts. > >> > > >> > Anyway, thanks for the clarification, I now understand why > abstractions > >> > over > >> > for loops need to use split-for-body. > >> > > >> > Carl Eastlund > >> > > >> > > >> > On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt > >> > wrote: > >> >> > >> >> Sorry that I forgot to add the `let` while turning the code you sent > >> >> into a full example. Here's another try. > >> >> > >> >> #lang racket/base > >> >> (require (for-syntax racket/base > >> >> syntax/parse > >> >> syntax/for-body)) > >> >> > >> >> (define-syntax (for/print/good stx) > >> >> (syntax-parse stx > >> >> [(_ clauses . body) > >> >> (with-syntax ([([pre ...] [post ...]) (split-for-body stx > >> >> #'body)]) > >> >>(syntax > >> >> (for clauses > >> >> pre ... > >> >> (printf "~v\n" (let () post ...)])) > >> >> > >> >> (define-syntax-rule (for/print/fixed/not clauses pre ... result) > >> >> (for clauses > >> >> pre ... > >> >> (printf "~v\n" (let () result > >> >> > >> >> (for/print/fixed/not ([i 1]) > >> >> (define (fish? v) (or (red? v) (blue? v))) > >> >> (begin > >> >> (define (red? v) (eq? v 'red)) > >> >> (define (blue
Re: [racket-dev] split-for-body from syntax/for-body
Okay, I see what's going on here. It's very subtle though, and probably deserves some explanation in split-for-body's documentation. My first thought on seeing my non-fix version break here is that I can make split-for-body break the same way. The problem is that my non-fix separates the definition of fish? from the definitions of red? and blue?, which it depends on. I can make split-for-body separate them the same way, by putting a #:break or #:final clause in between the definition of fish? and the begin form. The problem with doing so is a subtle point about for loops that is only mentioned in the last sentence of the last paragraph of the documentation of for itself: "Among the bodys, besides stopping the iteration and preventing later bodyevaluations, a #:break guard-expr or #:final guard-expr clause starts a new internal-definition context." So that's what split-for-body is preserving, the boundaries between internal definition contexts. That's not at all what I had expected it was doing; I had no idea the body of a for loop constituted multiple such contexts. Anyway, thanks for the clarification, I now understand why abstractions over for loops need to use split-for-body. Carl Eastlund On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt wrote: > Sorry that I forgot to add the `let` while turning the code you sent > into a full example. Here's another try. > > #lang racket/base > (require (for-syntax racket/base > syntax/parse > syntax/for-body)) > > (define-syntax (for/print/good stx) > (syntax-parse stx > [(_ clauses . body) > (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) >(syntax > (for clauses > pre ... > (printf "~v\n" (let () post ...)])) > > (define-syntax-rule (for/print/fixed/not clauses pre ... result) > (for clauses > pre ... > (printf "~v\n" (let () result > > (for/print/fixed/not ([i 1]) > (define (fish? v) (or (red? v) (blue? v))) > (begin > (define (red? v) (eq? v 'red)) > (define (blue? v) (eq? v 'blue)) > (fish? i))) > > At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote: > > You're proving that (let () ...) is necessary, which I have explicitly > > agreed with since the original email, but you have not yet demonstrated > > that split-for-body is necessary. Here is the fix I have described twice > > already, now explicitly put into the define-syntax-rule solution: > > > > (define-syntax-rule (for/print/fixed clauses pre .. result) > > (for clauses > > pre ... > > (printf "~v\n" (let () result > > > > Carl Eastlund > > > > > > On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt > wrote: > > > > > > > > #lang racket/base > > > (require (for-syntax racket/base > > > syntax/parse > > > syntax/for-body)) > > > > > > (define-syntax (for/print/good stx) > > > (syntax-parse stx > > > [(_ clauses . body) > > > (with-syntax ([([pre ...] [post ...]) (split-for-body stx > #'body)]) > > >(syntax > > > (for clauses > > > pre ... > > > (printf "~v\n" (let () post ...)])) > > > > > > (define-syntax-rule (for/print/bad clauses pre ... result) > > > (for clauses > > > pre ... > > > (printf "~v\n" result))) > > > > > > ;; Try changing to for/print/bad: > > > (for/print/good ([i 1]) > > > (define (fish? v) (or (red? v) (blue? v))) > > > (begin > > > (define (red? v) (eq? v 'red)) > > > (define (blue? v) (eq? v 'blue)) > > > (fish? i))) > > > > > > > > > At Fri, 6 Sep 2013 12:17:56 -0400, Carl Eastlund wrote: > > > > Right, that's the issue with needing the (let () result) in my > > > > define-syntax-rule version. I still didn't need split-for-body, > which > > > > doesn't guarantee there are no definitions in the post ... part. > All it > > > > guarantees to eliminate are #:final and #:break. > > > > > > > > Carl Eastlund > > > > > > > > > > > > On Fri, Sep 6, 2013 at 12:09 PM, Matthew Flatt > > > wrote: > > > > > > > > > The issue is `begin` splicing. The `result` form could be a `begin` > > > > > form that contains definitions that are referenced by a pre
Re: [racket-dev] split-for-body from syntax/for-body
They have to be separate internal definition contexts in order for #:break and #:final to be able to stop execution before the definitions themselves get run. Carl Eastlund On Fri, Sep 6, 2013 at 2:31 PM, Stephen Chang wrote: > > "Among the bodys, besides stopping the iteration and preventing later > body evaluations, a #:break guard-expr or #:final guard-expr clause starts > a new internal-definition context." > > I had the same thought process as Carl. I now understand the behavior > but I don't understand why it's needed? It seems kind of arbitrary > since no other form allows multiple internal def contexts in the body > like this. Is there a practical example? > > On Fri, Sep 6, 2013 at 12:58 PM, Carl Eastlund wrote: > > Okay, I see what's going on here. It's very subtle though, and probably > > deserves some explanation in split-for-body's documentation. > > > > My first thought on seeing my non-fix version break here is that I can > make > > split-for-body break the same way. The problem is that my non-fix > separates > > the definition of fish? from the definitions of red? and blue?, which it > > depends on. I can make split-for-body separate them the same way, by > > putting a #:break or #:final clause in between the definition of fish? > and > > the begin form. > > > > The problem with doing so is a subtle point about for loops that is only > > mentioned in the last sentence of the last paragraph of the > documentation of > > for itself: > > > > "Among the bodys, besides stopping the iteration and preventing later > body > > evaluations, a #:break guard-expr or #:final guard-expr clause starts a > new > > internal-definition context." > > > > So that's what split-for-body is preserving, the boundaries between > internal > > definition contexts. That's not at all what I had expected it was > doing; I > > had no idea the body of a for loop constituted multiple such contexts. > > > > Anyway, thanks for the clarification, I now understand why abstractions > over > > for loops need to use split-for-body. > > > > Carl Eastlund > > > > > > On Fri, Sep 6, 2013 at 12:38 PM, Matthew Flatt > wrote: > >> > >> Sorry that I forgot to add the `let` while turning the code you sent > >> into a full example. Here's another try. > >> > >> #lang racket/base > >> (require (for-syntax racket/base > >> syntax/parse > >> syntax/for-body)) > >> > >> (define-syntax (for/print/good stx) > >> (syntax-parse stx > >> [(_ clauses . body) > >> (with-syntax ([([pre ...] [post ...]) (split-for-body stx #'body)]) > >>(syntax > >> (for clauses > >> pre ... > >> (printf "~v\n" (let () post ...)])) > >> > >> (define-syntax-rule (for/print/fixed/not clauses pre ... result) > >> (for clauses > >> pre ... > >> (printf "~v\n" (let () result > >> > >> (for/print/fixed/not ([i 1]) > >> (define (fish? v) (or (red? v) (blue? v))) > >> (begin > >> (define (red? v) (eq? v 'red)) > >> (define (blue? v) (eq? v 'blue)) > >> (fish? i))) > >> > >> At Fri, 6 Sep 2013 12:30:17 -0400, Carl Eastlund wrote: > >> > You're proving that (let () ...) is necessary, which I have explicitly > >> > agreed with since the original email, but you have not yet > demonstrated > >> > that split-for-body is necessary. Here is the fix I have described > >> > twice > >> > already, now explicitly put into the define-syntax-rule solution: > >> > > >> > (define-syntax-rule (for/print/fixed clauses pre .. result) > >> > (for clauses > >> > pre ... > >> > (printf "~v\n" (let () result > >> > > >> > Carl Eastlund > >> > > >> > > >> > On Fri, Sep 6, 2013 at 12:25 PM, Matthew Flatt > >> > wrote: > >> > > >> > > > >> > > #lang racket/base > >> > > (require (for-syntax racket/base > >> > > syntax/parse > >> > > syntax/for-body)) > >> > > > >> > > (define-syntax (for/print/good stx) > >> > > (syntax-parse stx > >> > > [(_ cl
Re: [racket-dev] Output value of program changes depending on whether I pretty-print an opaque struct value
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 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" > To: "J. Ian Johnson" > Cc: "dev" > 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?
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 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 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 > 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] can a syntax-class "inherit" attributes?
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 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
I think it is a good idea to let multiple kinds of sets interact, but at the time I implemented all this I wasn't sure exactly how to make it work, so I took a conservative approach -- make it an error now; then we can make it a non-error later any way we want, without constraint. I don't want to give the impression I'm against interoperation. Here's what I propose to do now: - rename set? to generic-set?; this predicate recognizes the new all-inclusive generic set type - rename set-immutable? to set?; this predicate recognizes the pre-existing immutable hash set type - leave set-mutable? and set-weak? alone; they recognize the other two hash set types (on the mutability axis) - allow multiple-set operations to combine equal-based hash sets and lists, since both use equal? for equality I don't know how to make other user-defined types recognize when they share a notion of equality. I'm not 100% sure that rejecting these operations when sets don't share a notion of equality is actually the right thing to do; sometimes it's best to just let the user take responsibility for whether putting the elements of one set into another will have meaningful results. But that restriction is documented and predates my changes, so I'm leaving it in unless someone wants to propose a better way. That means rejecting all other kinds of sets beyond hash sets and lists for union, intersection, etc. Carl Eastlund On Thu, Aug 22, 2013 at 12:27 PM, Matthias Felleisen wrote: > > I can see why an eq-set and an eqv-set can't be union-ed without > additional information about the desired result type. > > But if we had two different implementation of the eq-set API we could > easily define unions as derived code; that's the point of OO. > > > > > > > On Aug 22, 2013, at 12:14 PM, Carl Eastlund 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 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" >> To: "J. Ian Johnson" , "Carl Eastlund" > > >> Cc: dev@racket-lang.org, "Matthew Flatt" >> 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 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" >> > To: "J. Ian Johnson" >> > Cc: dev@racket-lang.org, "Matthew Flatt" >> > 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" &
Re: [racket-dev] Lists aren't sets, but have set-like operations
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 wrote: > 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 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 > 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" > >> To: "J. Ian Johnson" , "Carl Eastlund" < > c...@ccs.neu.edu> > >> Cc: dev@racket-lang.org, "Matthew Flatt" > >> 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 > 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" > >> > To: "J. Ian Johnson" > >> > Cc: dev@racket-lang.org, "Matthew Flatt" > >> > 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. > >> > Generi
Re: [racket-dev] Lists aren't sets, but have set-like operations
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 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" > To: "J. Ian Johnson" , "Carl Eastlund" > Cc: dev@racket-lang.org, "Matthew Flatt" > 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 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" > > To: "J. Ian Johnson" > > Cc: dev@racket-lang.org, "Matthew Flatt" > > 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
Re: [racket-dev] Lists aren't sets, but have set-like operations
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 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" > To: "J. Ian Johnson" > Cc: "dev" > 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] 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 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
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 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 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 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" >>> To: "J. Ian Johnson" >>> Cc: "dev" >>> 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.
Re: [racket-dev] Generics scoping issues
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 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 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" >> To: "J. Ian Johnson" >> Cc: "dev" >> 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 un
Re: [racket-dev] Generics scoping issues
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 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" > To: "J. Ian Johnson" > Cc: "dev" > 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
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 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" > To: "J. Ian Johnson" > Cc: "dev" > 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
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 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 updates
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 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 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
On Fri, Aug 2, 2013 at 1:47 PM, Stephen Chang 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
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 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 > 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 > >> > 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 > 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 > >> >
Re: [racket-dev] Generics updates
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 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 > 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 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 > 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&quo
Re: [racket-dev] Generics updates
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 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 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 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] git submodule for native-library packages
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 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?
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" 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
Re: [racket-dev] package scopes
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 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
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 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] Broken docs
That fixed it, thanks Matthew! Carl Eastlund On Thu, Jul 25, 2013 at 11:54 AM, Matthew Flatt 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
[racket-dev] Broken docs
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] Generics updates
Thanks for those pointers, Tobias, I'll get those fixed. Carl Eastlund On Wed, Jul 24, 2013 at 1:34 PM, Tobias Hammer 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 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<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 >> > > > -- > --**--- > 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
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] Pre-Release Checklist for v5.3.6
On Mon, Jul 22, 2013 at 3:13 PM, Ryan Culpepper wrote: > * Carl Eastlund > - Dracula Tests (confirm that Dracula runs from PLaneT) > Done. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `#%declare' and cross-phase persistent modules
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 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 > /errortrace-doc/errortrace/scribblings > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /errortrace-lib/errortrace > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /errortrace-lib/errortrace > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /errortrace-lib/errortrace > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /errortrace-lib/errortrace > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /errortrace-lib/errortrace > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /errortrace-lib/errortrace/lang > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /algol60 > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/drscheme > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/drracket > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/drracket/private > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/scribble/tools > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/scribblings/tools > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/scribblings/tools > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/scribblings/tools > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/scribblings/drracket > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/drracket/private > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/scribblings/drracket > raco setup: module: does not satisfy cross-phase persistent grammar > raco setup: > raco setup: error: during making for /drracket/drracket/private > raco setup: module: does not satisfy cross-phase persistent grammar > > On Mon, Jul 22, 2013 at 12:18 PM, Matthew Flatt > 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,
Re: [racket-dev] expand, local-expand, and syntax-procedure-converted-arguments-property
Carl Eastlund On Wed, Jul 10, 2013 at 11:28 PM, Matthew Flatt 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
Re: [racket-dev] Compilation dependencies
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 /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 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
[racket-dev] Compilation dependencies
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
[racket-dev] generate-temporaries and #%top
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] Generics update
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] Package compatibility
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] A broken contract test & feature
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 wrote: > 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 "/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 wrote: > >> 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
Re: [racket-dev] dependencies for `racket-test` package
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 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] Package management
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 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
[racket-dev] Package management
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] Things we could move out of the core
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 wrote: > > 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
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 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?
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
Re: [racket-dev] ready for the package switch?
On Tue, Jun 18, 2013 at 2:02 PM, Eli Barzilay 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] hash->list stability?
On Tue, Jun 18, 2013 at 3:21 PM, Dan Liebgold wrote: > 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?
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 I 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. 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 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
[racket-dev] Generics
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] experience using the `pkg` branch
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 wrote: > 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 > 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 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 > >> 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: > >
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
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 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] Racket build dependencies
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 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 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 >> _rkt.zo I want to create _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] experience using the `pkg` branch
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 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
Re: [racket-dev] Racket build dependencies
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 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 > _rkt.zo I want to create _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
[racket-dev] Racket build dependencies
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 _rkt.zo I want to create _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
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 wrote: > 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
Re: [racket-dev] [plt] Push #26936: master branch updated
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
wrote:
> 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 2013-06-06 18:02
>> :
>> | Document procedure-closure-contents-eq?.
>> :
>> M collects/scribblings/reference/procedures.scrbl | 5 +
>>
>> ~~
>>
>> 6e8c9ed Vincent St-Amour 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] Unique identifiers
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 wrote: > 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 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 > > 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 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) > >>
Re: [racket-dev] Unique identifiers
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 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
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 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 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
[racket-dev] Unique identifiers
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] Constructing an identifier to an unexported binding
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 wrote: > 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 wrote: > > On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper > 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
On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper 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
On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen wrote: > > On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt > 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- 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] proposal for moving to packages: repository
On Thu, May 23, 2013 at 7:09 AM, Eli Barzilay wrote: > Just now, Carl Eastlund wrote: > > On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay 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] proposal for moving to packages: repository
On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay wrote: > A few minutes ago, Carl Eastlund wrote: > > On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay 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
On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay 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
On Wed, May 22, 2013 at 8:21 PM, Matthew Flatt 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
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 >> 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
On Mon, May 20, 2013 at 4:58 PM, Asumu Takikawa 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
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 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
On Mon, Apr 22, 2013 at 11:29 PM, Ryan Culpepper wrote > * Carl Eastlund > - 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
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 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 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 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 2013-03-30 11:49 > > > : > > > | Re-provide normalize-arity from racket/function. > > > : > > > M collects/racket/function.rkt | 4 ++-- > > > > > > ~~ > > > > > > 4dd011a Carl Eastlund 2013-03-30 15:49 > > > : > > > | Added documentation for normalize-arity. > > > : > > > M collects/scribblings/reference/procedures.scrbl | 42 > > ++ > > > > > > ~~ > > > > > > 636f8a9 Carl Eastlund 2013-03-30 21:04 > > > : > > > | Moved normalized-arity?, arity=?, and arity-includes? into > racket/ > > function. > >
Re: [racket-dev] [plt] Push #26536: master branch updated
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 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 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 2013-03-30 11:49 > > : > > | Re-provide normalize-arity from racket/function. > > : > > M collects/racket/function.rkt | 4 ++-- > > > > ~~ > > > > 4dd011a Carl Eastlund 2013-03-30 15:49 > > : > > | Added documentation for normalize-arity. > > : > > M collects/scribblings/reference/procedures.scrbl | 42 > ++ > > > > ~~ > > > > 636f8a9 Carl Eastlund 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 2013-03-30 21:05 > > : > > | Documented normalized-arity?, arity=?, and arity-includes?. > > : > > M collects/scribblings/reference/procedures.scrbl | 87 > +++--- > > > > ~~ > > > > f509420 Carl Eastlund 2013-03-30 17:12 > > : > > | Removed unnecessary duplication of normalize-arity. > > : > > M collects/tests/racket/fixnum.rktl | 21 ++--- > > > > ~~ > > > > df00bbb Carl Eastlund 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] Cross-phase persistent modules
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 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
[racket-dev] Cross-phase persistent modules
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
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 wrote: > > Greetings. > > On 2013 Feb 27, at 01:14, Matthew Flatt 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 >wrote: > >> > >>> At Tue, 26 Feb 2013 16:59:01 -0500, > >>> mfl...@racket-lang.org wrote: > >>>> 899a327 Matthew Flatt 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
Re: [racket-dev] http vs https urls for pnr.racket-lang.org
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 wrote: > 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 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 > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] http vs https urls for pnr.racket-lang.org
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] Pre-Release Checklist for v5.3.2
On Thu, Jan 17, 2013 at 1:46 PM, Ryan Culpepper wrote: > * Carl Eastlund > - Dracula Tests (confirm that Dracula runs from PLaneT) > Done. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket sources getting mysteriously out of sync
Recently I've run into some odd cases where I run "raco setup" and it rebuilds a whole bunch of stuff that should have been up-to-date. For instance, I have seen it rebuild all of the collections in a downloaded, pre-built installation of Racket that I had been using for a while. After the rebuild, many uses of "raco make" sped way up -- somehow, having out of sync collections slowed it down, yet it was not amortizing this cost by bringing them up to date as it went. Just now, I built an up-to-date git checkout from scratch, up through make install, then ran raco setup again and watched it re-run and re-render all of the Scribble documentation. Has anyone else seen behavior like this? Is there some way I might be misconfiguring things that would cause this? I'm mystified, and I'd like to stop wasting time rebuilding things over and over. For reference, I always have the following environment variables set: PLTHOME = root of whichever PLT tree I am using PLTADDONDIR = $PLTHOME/add-on PLTPLANETDIR=$PLTHOME/add-on/planet PLTCOMPILEDROOTS=$PLTHOME/zos/v@(version): Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Attempted clarification for planet2 docs
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 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 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 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.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
>>>> 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
>>> Assistant Professor / Brigham Young University
>>> http://faculty.cs.byu.edu/~jay
>>>
>>> "The glory of God is Intelligence" - D&C 93
>>>
>>> _
>>> Racket Developers list:
>>> http://lists.racket-lang.org/dev
>>>
>>>
>>
>
>
> --
> Jay McCarthy
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Attempted clarification for planet2 docs
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 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
> 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
>> 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
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] raco make clean
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
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 wrote: > 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 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 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 > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] first and rest in racket/base
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 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
Throw cons? in with empty?, please. Carl Eastlund On Thu, Dec 13, 2012 at 2:13 PM, Asumu Takikawa 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] planet2 and versions
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 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
[racket-dev] Planet 2 default package name services
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] And/or as procedures when not in application position
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 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
