Re: [racket-dev] `math' compilation time !!!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27-02-13 21:51, Neil Toronto wrote: > (An example that came up in the implementation of matrix norms: the > type of (sqrt (/ 1 x)) isn't Nonnegative-Real if x : > Nonnegative-Real, but Complex. Consider x = -0.0. Without TR's > complaints, `matrix-norm' would have contained a time bomb.) Should -0.0 really be a Nonnegative-Real? Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEwYUEACgkQp/VmCx0OL2xaggCfUPkt0tdp8fnpo0/ig+3GacNH fQoAniPJdBWqzQhkJeZ7FU7qdPbhZgQ9 =BH1h -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Merging nonterminals in union-language
I am at Northeastern. I use my own address as a central point for the multiple present and past addresses, and usually don't bother spoofing the `from' header. Perhaps I'll add a note about that to my email signature. Thanks for the tips about reduction semantics! I've created a pull request. William Bowman On Thu, Feb 28, 2013 at 08:18:12PM -0600, Robby Findler wrote: > Yeah, I agree it does make sense to do this kind of merging with examples > like the one you posted or else you get very very bad performance in > matching. And the merging is coming about because of the way the language > is structured; it isn't accidental "lucky" merging; you expect the same > productions to show up multiple times because of the way the grammars are > constructed. > > Overall, I agree with you that this is a reasonable request. I would be > happier if I could say that Redex's module language were anywhere close to > being ready because if it were, there would be a better way to do this. But > in the meantime, I think your extension is a good one. Your email suggests > that you are unaffiliated but I think you're actually at Northeastern? Can > someone there help you make this push? If not, I'd be happy to do it. > > Meanwhile, as to your Redex code, two points about reduction-semantics > style: you should put both "v" and "E" into the extension not the > originals: typically both concepts are a part of standard reduction. But, > if you have a need of values in the original language, (for, say, defining > Eval) then you should make it a separate non-terminal, not a production of > 'e'. In your specific example, you run into trouble if you want to make > pair strict, since you want only (pair v v) in the v non-terminal, but > (pair e e) in the e non-terminal. FWIW. > > Robby > > > On Thu, Feb 28, 2013 at 3:04 PM, William J. Bowman > wrote: > > > By the way, when I was tinkering, I originally got my example working > > *without* merging nts (lines 1967-1983). I only added it after > > inspecting the output of `compiled-lang-lang'. The resulting > > union-language had the same nonterminal in a language several times with > > overlapping right-hand-sides, so I merged them > > > > William Bowman > > > > On Thu, Feb 28, 2013 at 02:05:59PM -0600, Robby Findler wrote: > > > The reason I didn't do that is very much related to lines 1967-1983 in > > your > > > diff. > > > > > > That isn't a good idea: what you really want to do there is check to see > > if > > > different patterns generate the same languages or not. But that's not > > > something that is easily done (I'm guessing it is computable, but very > > very > > > expensive. It may not be computable, tho, for all I know.) > > > > > > One could allow unioning by just keeping all productions, and I guess I > > > wouldn't mind an extension to define-union-language via a keyword that > > did > > > that, tho. > > > > > > In your case, is there not a way to refactor your grammars so that you > > > don't need this capability? Could you maybe make a small, representative > > > example to post to the list? I find that kind of thing to be quite > > helpful > > > for me to understand what the best change to Redex is. > > > > > > Robby > > > > > > > > > > > > On Thu, Feb 28, 2013 at 1:46 PM, William J. Bowman > > > wrote: > > > > > > > Hello all, > > > > > > > > I've been hacking on some languages in Redex, and found myself > > > > abstracting commons parts into base languages, and gradually building > > new > > > > languages via `define-extended-language' and `define-union-language'. > > > > Unfortunately, I hit a wall when I discovered `define-union-language' > > > > doesn't like to union languages that define the same nonterminals. > > > > > > > > Consider this toy example: > > https://gist.github.com/bluephoenix47/5054403 > > > > > > > > This seems like a sensible thing to want to do, so I forked racket > > wrote a > > > > patch: > > > > > > > > > > https://github.com/bluephoenix47/racket/commit/0a7781b2be2643778f8d8d10d771ab1ce2dc622b > > > > > > > > Unfortunately, several Redex tests fail (http://sprunge.us/fPHU) > > because > > > > they expect an error when languages which define the same nonterminals > > > > are used in `define-union-language'. > > > > > > > > Is this *desired* behavior? If so, why? It seems very reasonable to > > want > > > > to merge the nonterminals of languages. > > > > > > > > -- > > > > > > > > William J. Bowman > > > > > > > > _ > > > > Racket Developers list: > > > > http://lists.racket-lang.org/dev > > > > > > > > > > pgp-signature.txt Description: Digital Signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Merging nonterminals in union-language
Yeah, I agree it does make sense to do this kind of merging with examples like the one you posted or else you get very very bad performance in matching. And the merging is coming about because of the way the language is structured; it isn't accidental "lucky" merging; you expect the same productions to show up multiple times because of the way the grammars are constructed. Overall, I agree with you that this is a reasonable request. I would be happier if I could say that Redex's module language were anywhere close to being ready because if it were, there would be a better way to do this. But in the meantime, I think your extension is a good one. Your email suggests that you are unaffiliated but I think you're actually at Northeastern? Can someone there help you make this push? If not, I'd be happy to do it. Meanwhile, as to your Redex code, two points about reduction-semantics style: you should put both "v" and "E" into the extension not the originals: typically both concepts are a part of standard reduction. But, if you have a need of values in the original language, (for, say, defining Eval) then you should make it a separate non-terminal, not a production of 'e'. In your specific example, you run into trouble if you want to make pair strict, since you want only (pair v v) in the v non-terminal, but (pair e e) in the e non-terminal. FWIW. Robby On Thu, Feb 28, 2013 at 3:04 PM, William J. Bowman wrote: > By the way, when I was tinkering, I originally got my example working > *without* merging nts (lines 1967-1983). I only added it after > inspecting the output of `compiled-lang-lang'. The resulting > union-language had the same nonterminal in a language several times with > overlapping right-hand-sides, so I merged them > > William Bowman > > On Thu, Feb 28, 2013 at 02:05:59PM -0600, Robby Findler wrote: > > The reason I didn't do that is very much related to lines 1967-1983 in > your > > diff. > > > > That isn't a good idea: what you really want to do there is check to see > if > > different patterns generate the same languages or not. But that's not > > something that is easily done (I'm guessing it is computable, but very > very > > expensive. It may not be computable, tho, for all I know.) > > > > One could allow unioning by just keeping all productions, and I guess I > > wouldn't mind an extension to define-union-language via a keyword that > did > > that, tho. > > > > In your case, is there not a way to refactor your grammars so that you > > don't need this capability? Could you maybe make a small, representative > > example to post to the list? I find that kind of thing to be quite > helpful > > for me to understand what the best change to Redex is. > > > > Robby > > > > > > > > On Thu, Feb 28, 2013 at 1:46 PM, William J. Bowman > > wrote: > > > > > Hello all, > > > > > > I've been hacking on some languages in Redex, and found myself > > > abstracting commons parts into base languages, and gradually building > new > > > languages via `define-extended-language' and `define-union-language'. > > > Unfortunately, I hit a wall when I discovered `define-union-language' > > > doesn't like to union languages that define the same nonterminals. > > > > > > Consider this toy example: > https://gist.github.com/bluephoenix47/5054403 > > > > > > This seems like a sensible thing to want to do, so I forked racket > wrote a > > > patch: > > > > > > > https://github.com/bluephoenix47/racket/commit/0a7781b2be2643778f8d8d10d771ab1ce2dc622b > > > > > > Unfortunately, several Redex tests fail (http://sprunge.us/fPHU) > because > > > they expect an error when languages which define the same nonterminals > > > are used in `define-union-language'. > > > > > > Is this *desired* behavior? If so, why? It seems very reasonable to > want > > > to merge the nonterminals of languages. > > > > > > -- > > > > > > William J. Bowman > > > > > > _ > > > Racket Developers list: > > > http://lists.racket-lang.org/dev > > > > > > > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] patch for double spaced autobib
Attached is a patch that adds a keyword, #spaces, to `define-cite', which makes
the generate bibliography have N spaces between each entry.
(define-cite ... g #:spaces 2)
(g)
..output..
[1] entry 1
[2] entry 2
If it looks ok I can push it, and update the docs as well.
diff --git a/collects/scriblib/autobib.rkt b/collects/scriblib/autobib.rkt
index 4d31b69..a6baa61 100644
--- a/collects/scriblib/autobib.rkt
+++ b/collects/scriblib/autobib.rkt
@@ -222,7 +222,8 @@
(define (gen-bib tag group sec-title
style maybe-disambiguator
maybe-render-date-bib maybe-render-date-cite
- maybe-datepara bib (and ambiguous?? (disambiguator num-ambiguous*)) i))
(values bib num-ambiguous* (cons para* rev-disambiguated*
(reverse rev-disambiguated*)))
+
+ (define (make-space)
+(list
+ (make-paragraph (make-style #f '()) '(""))
+ (make-paragraph (make-style #f '()) '(""
+
(make-part #f
`((part ,tag))
(list sec-title)
(make-style #f '(unnumbered))
null
- (list (make-table (send style bibliography-table-style) disambiguated))
+ (list (make-table (send style bibliography-table-style)
+ (add-between #:splice? #t
+disambiguated
+(for/list ([i (in-range 1 spaces)])
+ (make-space)
null))
(define (bib->entry bib style disambiguation render-date-bib i)
@@ -353,6 +364,7 @@
(~or (~optional (~seq #:style style) #:defaults ([style #'author+date-style]))
(~optional (~seq #:disambiguate fn) #:defaults ([fn #'#f]))
(~optional (~seq #:render-date-in-bib render-date-bib) #:defaults ([render-date-bib #'#f]))
+ (~optional (~seq #:spaces spaces) #:defaults ([spaces #'1]))
(~optional (~seq #:render-date-in-cite render-date-cite) #:defaults ([render-date-cite #'#f]))
(~optional (~seq #:datestring e)))
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Merging nonterminals in union-language
By the way, when I was tinkering, I originally got my example working *without* merging nts (lines 1967-1983). I only added it after inspecting the output of `compiled-lang-lang'. The resulting union-language had the same nonterminal in a language several times with overlapping right-hand-sides, so I merged them William Bowman On Thu, Feb 28, 2013 at 02:05:59PM -0600, Robby Findler wrote: > The reason I didn't do that is very much related to lines 1967-1983 in your > diff. > > That isn't a good idea: what you really want to do there is check to see if > different patterns generate the same languages or not. But that's not > something that is easily done (I'm guessing it is computable, but very very > expensive. It may not be computable, tho, for all I know.) > > One could allow unioning by just keeping all productions, and I guess I > wouldn't mind an extension to define-union-language via a keyword that did > that, tho. > > In your case, is there not a way to refactor your grammars so that you > don't need this capability? Could you maybe make a small, representative > example to post to the list? I find that kind of thing to be quite helpful > for me to understand what the best change to Redex is. > > Robby > > > > On Thu, Feb 28, 2013 at 1:46 PM, William J. Bowman > wrote: > > > Hello all, > > > > I've been hacking on some languages in Redex, and found myself > > abstracting commons parts into base languages, and gradually building new > > languages via `define-extended-language' and `define-union-language'. > > Unfortunately, I hit a wall when I discovered `define-union-language' > > doesn't like to union languages that define the same nonterminals. > > > > Consider this toy example: https://gist.github.com/bluephoenix47/5054403 > > > > This seems like a sensible thing to want to do, so I forked racket wrote a > > patch: > > > > https://github.com/bluephoenix47/racket/commit/0a7781b2be2643778f8d8d10d771ab1ce2dc622b > > > > Unfortunately, several Redex tests fail (http://sprunge.us/fPHU) because > > they expect an error when languages which define the same nonterminals > > are used in `define-union-language'. > > > > Is this *desired* behavior? If so, why? It seems very reasonable to want > > to merge the nonterminals of languages. > > > > -- > > > > William J. Bowman > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > > pgp-signature.txt Description: Digital Signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Merging nonterminals in union-language
I had a feeling I was doing something wrong, but I'm not familiar enough with the Redex source to do much more than hack until it does what I want :) Here is a small example of what I'd like to do: https://gist.github.com/bluephoenix47/5059837 This example seems to work with my patch, but obviously doesn't without it. William Bowman On Thu, Feb 28, 2013 at 02:05:59PM -0600, Robby Findler wrote: > The reason I didn't do that is very much related to lines 1967-1983 in your > diff. > > That isn't a good idea: what you really want to do there is check to see if > different patterns generate the same languages or not. But that's not > something that is easily done (I'm guessing it is computable, but very very > expensive. It may not be computable, tho, for all I know.) > > One could allow unioning by just keeping all productions, and I guess I > wouldn't mind an extension to define-union-language via a keyword that did > that, tho. > > In your case, is there not a way to refactor your grammars so that you > don't need this capability? Could you maybe make a small, representative > example to post to the list? I find that kind of thing to be quite helpful > for me to understand what the best change to Redex is. > > Robby > > > > On Thu, Feb 28, 2013 at 1:46 PM, William J. Bowman > wrote: > > > Hello all, > > > > I've been hacking on some languages in Redex, and found myself > > abstracting commons parts into base languages, and gradually building new > > languages via `define-extended-language' and `define-union-language'. > > Unfortunately, I hit a wall when I discovered `define-union-language' > > doesn't like to union languages that define the same nonterminals. > > > > Consider this toy example: https://gist.github.com/bluephoenix47/5054403 > > > > This seems like a sensible thing to want to do, so I forked racket wrote a > > patch: > > > > https://github.com/bluephoenix47/racket/commit/0a7781b2be2643778f8d8d10d771ab1ce2dc622b > > > > Unfortunately, several Redex tests fail (http://sprunge.us/fPHU) because > > they expect an error when languages which define the same nonterminals > > are used in `define-union-language'. > > > > Is this *desired* behavior? If so, why? It seems very reasonable to want > > to merge the nonterminals of languages. > > > > -- > > > > William J. Bowman > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > > > pgp-signature.txt Description: Digital Signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Merging nonterminals in union-language
The reason I didn't do that is very much related to lines 1967-1983 in your diff. That isn't a good idea: what you really want to do there is check to see if different patterns generate the same languages or not. But that's not something that is easily done (I'm guessing it is computable, but very very expensive. It may not be computable, tho, for all I know.) One could allow unioning by just keeping all productions, and I guess I wouldn't mind an extension to define-union-language via a keyword that did that, tho. In your case, is there not a way to refactor your grammars so that you don't need this capability? Could you maybe make a small, representative example to post to the list? I find that kind of thing to be quite helpful for me to understand what the best change to Redex is. Robby On Thu, Feb 28, 2013 at 1:46 PM, William J. Bowman wrote: > Hello all, > > I've been hacking on some languages in Redex, and found myself > abstracting commons parts into base languages, and gradually building new > languages via `define-extended-language' and `define-union-language'. > Unfortunately, I hit a wall when I discovered `define-union-language' > doesn't like to union languages that define the same nonterminals. > > Consider this toy example: https://gist.github.com/bluephoenix47/5054403 > > This seems like a sensible thing to want to do, so I forked racket wrote a > patch: > > https://github.com/bluephoenix47/racket/commit/0a7781b2be2643778f8d8d10d771ab1ce2dc622b > > Unfortunately, several Redex tests fail (http://sprunge.us/fPHU) because > they expect an error when languages which define the same nonterminals > are used in `define-union-language'. > > Is this *desired* behavior? If so, why? It seems very reasonable to want > to merge the nonterminals of languages. > > -- > > William J. Bowman > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Merging nonterminals in union-language
Hello all, I've been hacking on some languages in Redex, and found myself abstracting commons parts into base languages, and gradually building new languages via `define-extended-language' and `define-union-language'. Unfortunately, I hit a wall when I discovered `define-union-language' doesn't like to union languages that define the same nonterminals. Consider this toy example: https://gist.github.com/bluephoenix47/5054403 This seems like a sensible thing to want to do, so I forked racket wrote a patch: https://github.com/bluephoenix47/racket/commit/0a7781b2be2643778f8d8d10d771ab1ce2dc622b Unfortunately, several Redex tests fail (http://sprunge.us/fPHU) because they expect an error when languages which define the same nonterminals are used in `define-union-language'. Is this *desired* behavior? If so, why? It seems very reasonable to want to merge the nonterminals of languages. -- William J. Bowman pgp-signature.txt Description: Digital Signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A standard for testing Racket's libraries?
FWIW, I wouldn't mind if someone wanted to add a flag to "raco test" that took a collection (or subcollection) and followed some standardized way to test it. I think that would help us bring the collections in line to test them that way. It would probably work best if we had someone that was actually willing to do the work to get a large number of collections to follow the plan, whatever "raco test --collection" ends up doing. Robby On Thu, Feb 28, 2013 at 6:42 AM, Jay McCarthy wrote: > On Wed, Feb 27, 2013 at 2:34 PM, Danny Yoo wrote: > > On Wed, Feb 27, 2013 at 1:36 PM, Robby Findler > > wrote: > >> I think that currently you can look at what drdr does. That's the best > we > >> have. > > > > I'll assume that this is the drdr collection in meta, > > > > http://git.racket-lang.org/plt/tree/HEAD:/collects/meta/drdr > > > > and not the drdr2 directory, right? > > > > No, I think Robby means (because it is what I would suggest) just go > to drdr.racket-lang.org and see what gets run from the tests directory > and the collection source directory. > > > > >> Meanwhile, I think that if you are willing to live a bit on the edge, > you > >> can try to run some reasonable looking tests (break something > intentionally > >> and make sure they complain, say) and then go ahead and push and let > drdr > >> sort things out more. Worst comes to worst, you just revert a commit > and try > >> again tomorrow, no? > > > > I am somewhat risk averse. "Skittish" is probably apt. I'd prefer to > > rerun re-run a collection-wide test immediately after a bug fix, while > > the change is still fresh in my mind. Some collections are harder to > > test this way, so DrDr plays its role, but for algorithmic or > > data-structure stuff, I should be able to easily run the tests that I > > can execute locally, before committing a patch to the central > > repository. > > I think it would be good to be able to say "raco test -c collection > tests/collection" does everything. You've found a case where that > fails, which while not exactly an error is non-robust code that could > change. > > > I can already do this, by spending time reading through the collection > > tree till I find the modules that drive the unit tests. Sometimes I > > do a manual "grep -r" for the word 'test' and hope for the best. I > > just wish I didn't have to do that manual search. And I sometimes get > > it wrong; e.g. the datalog thing from a day ago: I was testing a > > change to parser-tools, but couldn't find any tests for the > > parser-tools collection. The next best thing I could do was run tests > > on the collections that _use_ parser-tools, and that's how this topic > > got started. > > However, you'll never be able to cleanly specify what other > collections/modules you should look at it. Maybe when the majority of > the core are packages that express their dependencies you could run > the things that depend on what you are changing, but even then I doubt > you should be willing to do that. > > Jay > > -- > 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] A standard for testing Racket's libraries?
On Wed, Feb 27, 2013 at 2:34 PM, Danny Yoo wrote: > On Wed, Feb 27, 2013 at 1:36 PM, Robby Findler > wrote: >> I think that currently you can look at what drdr does. That's the best we >> have. > > I'll assume that this is the drdr collection in meta, > > http://git.racket-lang.org/plt/tree/HEAD:/collects/meta/drdr > > and not the drdr2 directory, right? > No, I think Robby means (because it is what I would suggest) just go to drdr.racket-lang.org and see what gets run from the tests directory and the collection source directory. > >> Meanwhile, I think that if you are willing to live a bit on the edge, you >> can try to run some reasonable looking tests (break something intentionally >> and make sure they complain, say) and then go ahead and push and let drdr >> sort things out more. Worst comes to worst, you just revert a commit and try >> again tomorrow, no? > > I am somewhat risk averse. "Skittish" is probably apt. I'd prefer to > rerun re-run a collection-wide test immediately after a bug fix, while > the change is still fresh in my mind. Some collections are harder to > test this way, so DrDr plays its role, but for algorithmic or > data-structure stuff, I should be able to easily run the tests that I > can execute locally, before committing a patch to the central > repository. I think it would be good to be able to say "raco test -c collection tests/collection" does everything. You've found a case where that fails, which while not exactly an error is non-robust code that could change. > I can already do this, by spending time reading through the collection > tree till I find the modules that drive the unit tests. Sometimes I > do a manual "grep -r" for the word 'test' and hope for the best. I > just wish I didn't have to do that manual search. And I sometimes get > it wrong; e.g. the datalog thing from a day ago: I was testing a > change to parser-tools, but couldn't find any tests for the > parser-tools collection. The next best thing I could do was run tests > on the collections that _use_ parser-tools, and that's how this topic > got started. However, you'll never be able to cleanly specify what other collections/modules you should look at it. Maybe when the majority of the core are packages that express their dependencies you could run the things that depend on what you are changing, but even then I doubt you should be willing to do that. Jay -- 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
