Re: [racket-dev] composing contexts in Redex?
On Mon, May 2, 2011 at 8:45 PM, Stephen Chang stch...@ccs.neu.edu wrote: Hmm, or maybe you've found a bug in my model. Either way, thanks for looking into this. I couldn't resist taking another look. Here's how I'd like to define it: (define-language unfortunate-loop (L hole (in-hole (L e) (λ x hole))) (A hole (in-hole L A))) An L is one level of applications. Its second production extends an L with one application on the outside and one lambda on the inside, thereby maintaining balance. An A is zero or more nested Ls. Unfortunately, this definition sends the Redex matcher into a loop. Matching term t against pattern A will use the second production of A and the first production of L to get back to where it started, matching t against A. (As Robby pointed out, maybe it should consider these choices a failure and turn to the other productions.) This definition can be salvaged by forcing A's second production to consume some input before consuming a possibly empty L: (define-language no-loop (A hole (in-hole (L e) (λ x A))) (L hole (in-hole (L e) (λ x hole The second A production wraps the L in an application and consequently expects an extra lambda before the next A. Alternatively, we could make L slightly unbalanced and account for the extra lambda in A's second production: (define-language also-no-loop (A hole (in-hole (L e) A)) (L (λ x hole) (in-hole (L e) (λ x hole I'm not happy with either of these definitions, though; they require too much thinking about how the matching algorithm will behave. I'm starting to think I was wrong when I suggested that we should make these definitions syntax errors and be done with it. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] added function to srfi-19....
I think it's a bad idea to extend the SRFI modules with new functions. Would it make sense to move functionality from SRFI-19 into `racket/date' and then add the new functions there (and maybe change the SRFI-19 implementation to re-export part of `racket/date')? At Tue, 3 May 2011 14:48:42 -0700, John Clements wrote: It was driving me crazy that srfi-19 had no way to convert seconds to times, especially given the fact that it appears that the internal representation used by srfi 19's time-utc was the result of (current-seconds) so I added seconds-time-utc and time-utc-seconds, along with test cases. Unfortunately, I have no obvious way of documenting them. Let me know if there's a way I should be documenting this, or if it's a bad idea to extend the interface like this. John Clements _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] added function to srfi-19....
On Tue, May 3, 2011 at 4:55 PM, Matthew Flatt mfl...@cs.utah.edu wrote: I think it's a bad idea to extend the SRFI modules with new functions. I agree with this. Would it make sense to move functionality from SRFI-19 into `racket/date' and then add the new functions there (and maybe change the SRFI-19 implementation to re-export part of `racket/date')? At Tue, 3 May 2011 14:48:42 -0700, John Clements wrote: It was driving me crazy that srfi-19 had no way to convert seconds to times, especially given the fact that it appears that the internal representation used by srfi 19's time-utc was the result of (current-seconds) so I added seconds-time-utc and time-utc-seconds, along with test cases. Unfortunately, I have no obvious way of documenting them. Let me know if there's a way I should be documenting this, or if it's a bad idea to extend the interface like this. John Clements _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Parallel build switched to use Places by default.
Have you fixed the freezing problem I reported under windows? If not, maybe we should re-disable it there (since I rarely get builds to complete with it enabled). Robby On Tue, May 3, 2011 at 4:20 PM, Kevin Tew t...@cs.utah.edu wrote: The parallel build has been changed again to use places by default. (The previous memory leak problems have been fixed.) This means that parallel zo and doc builds will use places instead of processes. Please look out for any unusual behavior and report bugs as usual Thanks, Kevin _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] added function to srfi-19....
On May 3, 2011, at 2:55 PM, Matthew Flatt wrote: I think it's a bad idea to extend the SRFI modules with new functions. Would it make sense to move functionality from SRFI-19 into `racket/date' and then add the new functions there (and maybe change the SRFI-19 implementation to re-export part of `racket/date')? Yes, that makes sense. In my experience, the only compelling reasons to use SRFI-19 are - date-string functions - string-date functions. - conversions to from julian dates. Any others come to mind? John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] added function to srfi-19....
15 minutes ago, Matthew Flatt wrote: I think it's a bad idea to extend the SRFI modules with new functions. Would it make sense to move functionality from SRFI-19 into `racket/date' and then add the new functions there (and maybe change the SRFI-19 implementation to re-export part of `racket/date')? +1, if possible -- maybe it will also solve the license issues with that file? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] strange performance on regexp-match: proposed patch
On Wednesday, Danny Yoo wrote: I've isolated a performance issue on form-urlencoded-alist. On strings with very long key/values, the code appears to consume an unusual amount of memory. Does the following look ok? I made a different change that simplifies the code and should be as fast as your version -- I basically just used #rx= to do the search then split on the results. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
