Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket
Yes, I think that would be great. Which string constants specifically were you planning to remove? I should probably check that they aren't used on planet. Robby On Mon, Jul 9, 2012 at 7:53 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2012-07-08 15:47:27 +0800, Grecks Grecks wrote: Hi, I post an issue on github 2 month before. [1]https://github.com/plt/racket/issues/101 For devs: while fixing this, I noticed that the code that used to implement this menu item is still around (along with string constants) but are unused. Should I remove that code while I'm at it? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket
On 2012-07-10 07:20:59 -0500, Robby Findler wrote: Which string constants specifically were you planning to remove? I should probably check that they aren't used on planet. The `slideshow-insert-pict-box` constant doesn't appear to be used. There are also `slideshow-hide-picts, `slideshow-show-picts, `slideshow-cannot-show-picts` as well---I'm not sure whether these are removable or not (I see they're used for a pict-snip%'s popup menu but I can't seem to trigger that menu in DrRacket). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket
Version 1.2 of cdrswift.plt seems to use the slideshow-insert-pict-box string constant, but it is up to version 1.5 now. http://planet.racket-lang.org/display.ss?package=cdrswift.pltowner=dignatof Probably best to just leave them in for now. Robby On Tue, Jul 10, 2012 at 8:48 AM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2012-07-10 07:20:59 -0500, Robby Findler wrote: Which string constants specifically were you planning to remove? I should probably check that they aren't used on planet. The `slideshow-insert-pict-box` constant doesn't appear to be used. There are also `slideshow-hide-picts, `slideshow-show-picts, `slideshow-cannot-show-picts` as well---I'm not sure whether these are removable or not (I see they're used for a pict-snip%'s popup menu but I can't seem to trigger that menu in DrRacket). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Enhancement to the syntax system?
20 minutes ago, Marijn wrote: It seems to me that both these results cannot be correct simultaneously, but I'll await the experts' opinion on that. This does look weird: #lang racket (define-for-syntax (f stx) #`(let ([x 1]) #,stx)) (define-syntax (m stx) (with-syntax ([zz (f #'x)]) #`(let ([x 2]) zz))) (m) evaluates to 1, but if I change the first two stx names into x *or* if I change the argument name for the macro to x, then it returns 2. -- ((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] Enhancement to the syntax system?
At Tue, 10 Jul 2012 10:51:57 -0400, Eli Barzilay wrote: 20 minutes ago, Marijn wrote: It seems to me that both these results cannot be correct simultaneously, but I'll await the experts' opinion on that. This does look weird: #lang racket (define-for-syntax (f stx) #`(let ([x 1]) #,stx)) (define-syntax (m stx) (with-syntax ([zz (f #'x)]) #`(let ([x 2]) zz))) (m) evaluates to 1, but if I change the first two stx names into x *or* if I change the argument name for the macro to x, then it returns 2. It's natural --- but not correct --- to think that #` is responsible for hygiene, in which case `(f #'x)' should keep the given `x' separate from the `let'-bound `x' in the result. Instead, hygiene is the responsibility of macro invocation, and #`(let ([x 1]) #,#'x) is simply the same as #`(let ([x 1]) x) and so (f #'x) above is equivalent to #`(let ([x 1]) x) If you change the example to #lang racket (begin-for-syntax (define-syntax-rule (f body) #`(let ([x 1]) body))) (define-syntax (m stx) (with-syntax ([zz (f x)]) #`(let ([x 2]) zz))) (m) so that `f' is used as a macro instead of a function, then you get 2, since the macro-expansion of `(f x)' keeps the `x's separate. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Enhancement to the syntax system?
On 07/10/2012 10:51 AM, Eli Barzilay wrote: 20 minutes ago, Marijn wrote: It seems to me that both these results cannot be correct simultaneously, but I'll await the experts' opinion on that. This does look weird: #lang racket (define-for-syntax (f stx) #`(let ([x 1]) #,stx)) (define-syntax (m stx) (with-syntax ([zz (f #'x)]) #`(let ([x 2]) zz))) (m) evaluates to 1, but if I change the first two stx names into x *or* if I change the argument name for the macro to x, then it returns 2. The difference between (define-for-syntax (f1 stx) #`(let ([x 1]) #,stx) and (define-for-syntax (f2 x) #`(let ([x 1]) #,x) is that the 'x' in the template in the 'f2' is not bound-identifier=? to the 'x' that appears in the template of 'm', because it has a rename wrap due to the 'x' formal parameter of 'f2'. That is, 'f2' behaves essentially the same as (define-for-syntax (f2* x*) #`(let ([x* 1]) #,x*) A likely mistake is to think that the wrap generated by the 'x' in 'f2' doesn't count because it happens before we get around to the real macro expansion that you care about. But that's not the case (at least in Racket). A good rule of thumb is to never use local variable names in your macro implementation (including compile-time auxiliary functions) that also appear in the macro's template (including etc). A related error is the identifier used out of context error that you get from, eg, (define-syntax (m stx) (let ([+ *]) #'(+ 1 2))) (m) ;; = identifier used out of context in: + The binding of '+' in the macro changes the meaning of the '+' in the template, even though the bindings exist at different phases. You could perhaps avoid this issue by changing the hygiene algorithm by adding a phase level to rename wraps and skipping different-phase rename wraps during resolution. I'm not sure if this is a good idea or if anyone has tried it. Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Enhancement to the syntax system?
samth made a pointer to http://srfi.schemers.org/srfi-72/srfi-72.html It does not look like guile racket etc. have implemented this yet. Am I wrong? This is precisely what I'm after! On Tue, Jul 10, 2012 at 5:26 PM, Ludovic Courtès l...@gnu.org wrote: Hi, Matthew Flatt mfl...@cs.utah.edu skribis: It's natural --- but not correct --- to think that #` is responsible for hygiene, in which case `(f #'x)' should keep the given `x' separate from the `let'-bound `x' in the result. [...] If you change the example to #lang racket (begin-for-syntax (define-syntax-rule (f body) #`(let ([x 1]) body))) (define-syntax (m stx) (with-syntax ([zz (f x)]) #`(let ([x 2]) zz))) (m) so that `f' is used as a macro instead of a function, then you get 2, since the macro-expansion of `(f x)' keeps the `x's separate. Interesting. Thanks for the clarification and examples. Ludo’. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket
At Tue, 10 Jul 2012 09:13:24 -0500, Robby Findler wrote: Version 1.2 of cdrswift.plt seems to use the slideshow-insert-pict-box string constant, but it is up to version 1.5 now. http://planet.racket-lang.org/display.ss?package=cdrswift.pltowner=dignatof Probably best to just leave them in for now. Should we deprecate it and put it on a 1 year counter? (like `mzlib/class100') Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket
I was thinking along similar lines. But maybe it would be helpful to do this for all of the unused string-constants in the tree? We could even move them into a planet package now. Robby On Tue, Jul 10, 2012 at 10:54 AM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Tue, 10 Jul 2012 09:13:24 -0500, Robby Findler wrote: Version 1.2 of cdrswift.plt seems to use the slideshow-insert-pict-box string constant, but it is up to version 1.5 now. http://planet.racket-lang.org/display.ss?package=cdrswift.pltowner=dignatof Probably best to just leave them in for now. Should we deprecate it and put it on a 1 year counter? (like `mzlib/class100') Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Insert Pict Box menu item not found in DrRacket
At Tue, 10 Jul 2012 11:23:04 -0500, Robby Findler wrote: I was thinking along similar lines. But maybe it would be helpful to do this for all of the unused string-constants in the tree? Good idea. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Enhancement to the syntax system?
Hi, Matthew Flatt mfl...@cs.utah.edu skribis: It's natural --- but not correct --- to think that #` is responsible for hygiene, in which case `(f #'x)' should keep the given `x' separate from the `let'-bound `x' in the result. [...] If you change the example to #lang racket (begin-for-syntax (define-syntax-rule (f body) #`(let ([x 1]) body))) (define-syntax (m stx) (with-syntax ([zz (f x)]) #`(let ([x 2]) zz))) (m) so that `f' is used as a macro instead of a function, then you get 2, since the macro-expansion of `(f x)' keeps the `x's separate. Interesting. Thanks for the clarification and examples. Ludo’. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Enhancement to the syntax system?
An hour and a half ago, Matthew Flatt wrote: It's natural --- but not correct --- to think that #` is responsible for hygiene, in which case `(f #'x)' should keep the given `x' separate from the `let'-bound `x' in the result. Instead, hygiene is the responsibility of macro invocation, and #`(let ([x 1]) #,#'x) is simply the same as #`(let ([x 1]) x) and so (f #'x) above is equivalent to #`(let ([x 1]) x) If you change the example to #lang racket (begin-for-syntax (define-syntax-rule (f body) #`(let ([x 1]) body))) (define-syntax (m stx) (with-syntax ([zz (f x)]) #`(let ([x 2]) zz))) (m) so that `f' is used as a macro instead of a function, then you get 2, since the macro-expansion of `(f x)' keeps the `x's separate. Yeah, I think that this kind of confusion is there, but it's easy (at least relatively easy) to build a mental model of how things work and avoid such problems -- but the tricky bit here is that things break when the `stx' is renamed to `x'. 50 minutes ago, Ryan Culpepper wrote: The difference between (define-for-syntax (f1 stx) #`(let ([x 1]) #,stx) and (define-for-syntax (f2 x) #`(let ([x 1]) #,x) is that the 'x' in the template in the 'f2' is not bound-identifier=? to the 'x' that appears in the template of 'm', because it has a rename wrap due to the 'x' formal parameter of 'f2'. That is, 'f2' behaves essentially the same as (define-for-syntax (f2* x*) #`(let ([x* 1]) #,x*) Yeah, I think that this is the more confusing bit. (I suspected something along this line, but didn't have time to figure out a good explanation...) So I think that the real confusion is actually a combination of what Matthew pointed at in the above and this one, making the result trickier than both. In other words, I *think* that the effect of the transformer's argument name makes it looks like the #` *was* responsible for hygiene when it's actually just this point that makes it happen... (This is all IIUC.) A likely mistake is to think that the wrap generated by the 'x' in 'f2' doesn't count because it happens before we get around to the real macro expansion that you care about. But that's not the case (at least in Racket). A good rule of thumb is to never use local variable names in your macro implementation (including compile-time auxiliary functions) that also appear in the macro's template (including etc). Yeah, and a subtle lesson here is that `stx' is a useful convention. (I think that `x' is common in some guile code, so this would be a point for them.) A related error is the identifier used out of context error that you get from, eg, (define-syntax (m stx) (let ([+ *]) #'(+ 1 2))) (m) ;; = identifier used out of context in: + The binding of '+' in the macro changes the meaning of the '+' in the template, even though the bindings exist at different phases. You could perhaps avoid this issue by changing the hygiene algorithm by adding a phase level to rename wraps and skipping different-phase rename wraps during resolution. I'm not sure if this is a good idea or if anyone has tried it. (And this is what Matthew's last example gets by changing `f' to a macro, right? Also, Stefan posted a related message to the scheme-reports list where he imlpemented some new #. thing which is (roughly speaking) something that expands to a `let-syntax' and therefore tries to do the same.) In any case, it would be nice if the original example I posted (which is a variant of what was discussed originally) would throw an error instead of looking right in a way that is wrong... -- ((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] Enhancement to the syntax system?
The question I posed was If it's possible to use srfi-72 in guile or racket. It is indeed a wish of mine that it's implemented because it will most certainly help me write beutiful code because that srfi cater to the coding style Ichoose to have. Without it one most certainly need to use with-syntax to introduce the bindings in order to be safe and avoid a multiple of possible syntactic loopholes as can see if you read André van Tonder's http://srfi.schemers.org/srfi-72/srfi-72.html Anyway one does not need to change psyntax in order to come close to that system. A more hacky way is to use code like the one at the end of this document. It's a reiteration and improvement on a previous version. So with this hack I can write, - (use-modules (syntax unquote++)) (define (f x y) #`(let ((x 1)) (+ #,x #,y))) (define (h y) ##`(let ((x 2)) #.((x) (f x y (define-syntax g (lambda (x) (syntax-case x () ((_ y) ##`(let ((x y)) #.((x) (h x))) scheme@(guile-user) (g 3) $2 = 5 -- In racket, (define-for-syntax (f x y) #`(let ((x 1)) (+ #,x #,y))) (define-for-syntax (h y) #`(let ((x 2)) #,(f #'x y)) (define-syntax (g stx) (syntax-case stx () ((_ y) #`(let ((x y)) #,(h #'x) (g 3) 4 -- This shows that it was just luck previously when racket produced the correct (for my intention) answer. with srfi-72 a correct answer would have been produced. Without srfi-72 I will then move over to use ##` and #. in my code because it will be easy to transfer later on if when srfi-72 is available in some form. /Stefan (define-module (syntax unquote++) #:export (quasisyntax++ insyntax)) (define *s* (make-fluid '())) (define *t* (make-fluid '())) (define table (make-weak-key-hash-table)) (define (add-lambda lam) (let* ((id (gensym id)) (x (datum-syntax #'table id))) (hashq-set! table id lam) x)) (define (plexer x . l) (let ((lam (hashq-ref table x))) (apply lam l))) (define (parse stx x) (syntax-case x (unsyntax insyntax unsyntax-splicing) ((unsyntax . _) x) ((unsyntax-splicing . _) x) ((insyntax ((p ...) c ...)) (with-syntax ((g (datum-syntax stx (gensym g))) (i (datum-syntax stx (gensym i (fluid-set! *s* (cons #'(g (lambda (x) (syntax-case x () ((_ p ...) (plexer 'i #'p ...) (fluid-ref *s*))) (fluid-set! *t* (cons #'(i (add-lambda (lambda (p ...) (begin c ... (fluid-ref *t*))) #'(g p ...))) ((x . l) (cons (parse stx #'x) (parse stx #'l))) (x #'x))) (define-syntax quasisyntax++ (lambda (x) (syntax-case x () ((_ y) (begin (fluid-set! *s* '()) (fluid-set! *t* '()) (with-syntax ((statement (parse x #'y)) (lets (fluid-ref *s*)) (withs (fluid-ref *t*))) #'(with-syntax withs #`(let-syntax lets statement (define (rg ch stream) (let ((x (read-char stream))) (cond ((eqv? x #\`) `(quasisyntax++ ,(read stream))) (#t (error Wrong format of # reader extension) (define (rg. ch stream) `(insyntax ,(read stream))) (read-hash-extend #\# rg) (read-hash-extend #\. rg.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Need a clarification on the implementation of stream-map
And thus, the type of stream-map is NOT stream-map : (a - b) (stream a) - (stream b) but stream-map : (a b c ... - d e f ...) (stream a b c ...) - (stream d e f ...) Jay On Sun, Jul 8, 2012 at 8:00 AM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not sure about the rationale behind the design of stream-map, but any as a result contract for a function indicates it may return multiple values (in the range of a function any is a special keyword). any/c is a contract for a single value. Robby On Sun, Jul 8, 2012 at 6:25 AM, Daniel King dank...@ccs.neu.edu wrote: Question 0: In collects/racket/stream.rkt, `stream-map' is defined as: (define (stream-map f s) (unless (procedure? f) (raise-argument-error 'stream-map procedure? f)) (unless (stream? s) (raise-argument-error 'stream-map stream? s)) (let loop ([s s]) (cond [(stream-empty? s) empty-stream] [else (stream-cons (call-with-values (lambda () (stream-first s)) f) (loop (stream-rest s)))]))) I don't understand the difference between: (call-with-values (lambda () (stream-first s)) f) and (f (stream-first s)) because the contract for `stream-first' is: (stream-first s) → any s : (and/c stream? (not/c stream-empty?)) Which seems to me to just return a single value. I was taking a second look at my changes to `stream-map' which add support for multiple streams. I noticed this unusual snippet as I rebased onto the latest version of plt/master. Question 1: Would it make more sense to simply update all the sequence procedures to handle multiple sequences? Is there a circumstance where it doesn't make sense to handle multiple sequences in a sequence procedure such as `sequence-map'? I figure that the sequence procedures don't support multiple sequences is just lack of interest. Do most people just use the `for' macros in these cases? -- Dan King College of Computer and Information Science Northeastern University _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
I've been looking forward to trying this since I read your paper draft last night. I didn't expect it so soon, though! Neil ⊥ On 07/10/2012 09:01 AM, jamesswa...@racket-lang.org wrote: jamesswaine has updated `master' from 48e154e3cb to dbec8765e3. http://git.racket-lang.org/plt/48e154e3cb..dbec8765e3 =[ 6 Commits ]== Directory summary: 34.5% collects/racket/future/private/ 43.6% collects/scribblings/guide/ 6.5% collects/scribblings/reference/ 11.1% collects/tests/future/ ~~ b6f71ec James Swaine jamesswa...@racket-lang.org 2012-02-29 11:43 : | Add futures visualizer, improvements to futures logging : A collects/racket/future/private/constants.rkt A collects/racket/future/private/display.rkt A collects/racket/future/private/drawing-helpers.rkt A collects/racket/future/private/graph-drawing.rkt A collects/racket/future/private/gui-helpers.rkt A collects/racket/future/private/visualizer-data.rkt A collects/racket/future/private/visualizer-drawing.rkt A collects/racket/future/private/visualizer-gui.rkt A collects/racket/future/visualizer.rkt M collects/scribblings/guide/futures.scrbl | 398 +--- A collects/scribblings/guide/mand-bad-hover.png A collects/scribblings/guide/mand-bad.png A collects/scribblings/guide/mand-good.png A collects/scribblings/guide/vis-main.png M collects/scribblings/reference/concurrency.scrbl | 1 + M collects/scribblings/reference/futures.scrbl | 18 +- A collects/scribblings/reference/futures-visualizer.scrbl A collects/tests/future/bad-trace1.rkt M collects/tests/future/future.rkt | 2 +- A collects/tests/future/visualizer.rkt A qsort2.rkt M src/racket/src/future.c | 145 +-- M src/racket/src/future.h | 2 +- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
Cool! On Tue, Jul 10, 2012 at 2:02 PM, Neil Toronto neil.toro...@gmail.comwrote: I've been looking forward to trying this since I read your paper draft last night. I didn't expect it so soon, though! Neil ⊥ On 07/10/2012 09:01 AM, jamesswa...@racket-lang.org wrote: jamesswaine has updated `master' from 48e154e3cb to dbec8765e3. http://git.racket-lang.org/**plt/48e154e3cb..dbec8765e3http://git.racket-lang.org/plt/48e154e3cb..dbec8765e3 =[ 6 Commits ]=** = Directory summary: 34.5% collects/racket/future/**private/ 43.6% collects/scribblings/guide/ 6.5% collects/scribblings/**reference/ 11.1% collects/tests/future/ ~~ b6f71ec James Swaine jamesswa...@racket-lang.org 2012-02-29 11:43 : | Add futures visualizer, improvements to futures logging : A collects/racket/future/**private/constants.rkt A collects/racket/future/**private/display.rkt A collects/racket/future/**private/drawing-helpers.rkt A collects/racket/future/**private/graph-drawing.rkt A collects/racket/future/**private/gui-helpers.rkt A collects/racket/future/**private/visualizer-data.rkt A collects/racket/future/**private/visualizer-drawing.rkt A collects/racket/future/**private/visualizer-gui.rkt A collects/racket/future/**visualizer.rkt M collects/scribblings/guide/**futures.scrbl | 398 +--- A collects/scribblings/guide/**mand-bad-hover.png A collects/scribblings/guide/**mand-bad.png A collects/scribblings/guide/**mand-good.png A collects/scribblings/guide/**vis-main.png M collects/scribblings/**reference/concurrency.scrbl | 1 + M collects/scribblings/**reference/futures.scrbl | 18 +- A collects/scribblings/**reference/futures-visualizer.**scrbl A collects/tests/future/bad-**trace1.rkt M collects/tests/future/future.**rkt | 2 +- A collects/tests/future/**visualizer.rkt A qsort2.rkt M src/racket/src/future.c | 145 +-- M src/racket/src/future.h | 2 +- _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Deprecating collects
Hi all, Recently, we've made some progress on getting rid of parts of our legacy codebase (e.g., mzlib/class100). Since a release is coming up, that is an opportunity to do more cleanup. Vincent and I have been brainstorming what other collections could be set on a 1-year deprecation removal notice. Here is a list of potential collections to deprecate with accompanying rationales. Some of these may still be useful and worth keeping around; we may have missed some of their use cases. This is just a first stab at it: - combinator-parser This library only has .txt documentaiton and looks bitrotted. There are no users of this collection as far as we know and it's unlikely to gain any (due to lack of documentation). - test-box-recovery A library for compatibility with the pre-v360 DrScheme format - tex2page Undocumented and it's unclear how it's related to Racket - defmacro in mzlib mzlib in general, but this one in particular because it is highly misleading for newcomers (who think it's a blessed macro facility). Has no real users in the core codebase (there are two requires in benchmarks but no uses) - mzlib Most of this library has been superceded and the rest should probably either be moved elsewhere (e.g., mzlib/control) or removed. - mzscheme This is a superceded, legacy language Some of these collections may have users outside of the codebase, but they are likely running on older versions of Racket anyway. Some of these collections could be turned into PLaneT packages instead. Any thoughts? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa wrote: - combinator-parser [...] - test-box-recovery [...] - tex2page [...] These seem fine with me, because I think they have no current users. We've had enough versions with the test-box recovery tool that if someone really needs it, they can run an older version to get to the new version. - defmacro in mzlib I'm skeptical that this one should be removed,. At a minimum, though, it could be better explained/discouraged in the docs for the hack that it is. - mzlib [...] - mzscheme [...] I don't think these should be removed or deprecated, ever. I have lots of code that still refers to them --- I doubt that I'm alone --- and I think we should be able to support them. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa wrote: - combinator-parser [...] - test-box-recovery [...] - tex2page [...] These seem fine with me, because I think they have no current users. We've had enough versions with the test-box recovery tool that if someone really needs it, they can run an older version to get to the new version. - defmacro in mzlib I'm skeptical that this one should be removed,. At a minimum, though, it could be better explained/discouraged in the docs for the hack that it is. Why do you want to keep this? - mzlib [...] - mzscheme [...] I don't think these should be removed or deprecated, ever. I have lots of code that still refers to them --- I doubt that I'm alone --- and I think we should be able to support them. I agree that these should never be removed. I would not mind if they were marked in some way as these are here for legacy reasons. New code should use XYZ with specific pointers and helpful advice. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Need a clarification on the implementation of stream-map
Sorry, I accidentally sent this off the mailing list and accidentally switched emails. Eli, I don't see any trace of multiple valued `stream's in racket/stream. Can you confirm or deny their existence? On Tue, Jul 10, 2012 at 11:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Eli wrote racket/stream based on racket/sequence which I wrote. You'll have to ask him whether he added support for multiple-value sequences and how to get them. Jay On Tue, Jul 10, 2012 at 4:15 PM, Daniel King dank...@cern.ch wrote: On Tue, Jul 10, 2012 at 9:06 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Your example is one-valued stream not a three-valued stream. How does one produce a stream with more than one-value? I assume that if there are no multi-valued streams then there is no need for the aforementioned snippet in the implementation of `stream-map'. -- Dan King Northeastern University -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 -- Dan King College of Computer and Information Science Northeastern University _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
- Original Message - I agree that these should never be removed. I would not mind if they were marked in some way as these are here for legacy reasons. New code should use XYZ with specific pointers and helpful advice. Okay, we will just add the deprecation notices to the documentation (using the same notice that `htdp/image` and `mzlib/class100` use) but otherwise won't touch `mzlib` and `mzscheme`. There are also some libraries that are still in `mzlib` (with pointers from `racket`) such as `unit` and `control`, so we will go ahead and move these to `racket` and leave pointers in `mzlib` (but legacy code should still work) unless anyone has any objections. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
Robby Findler wrote at 07/10/2012 05:20 PM: On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flattmfl...@cs.utah.edu wrote: - mzlib [...] - mzscheme [...] I don't think these should be removed or deprecated, ever. I have lots of code that still refers to them --- I doubt that I'm alone --- and I think we should be able to support them. I agree that these should never be removed. I would not mind if they were marked in some way as these are here for legacy reasons. New code should use XYZ with specific pointers and helpful advice. I'm still using some mzlib in *new* code. Specifically, getpid, this-expression-source-directory, gethostname, and perhaps one or two other things. I could find other ways to do those things if I had to, but those definitions pop up when I search, and there's no glaring warning not to use them. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
On Tue, Jul 10, 2012 at 6:44 PM, Neil Van Dyke n...@neilvandyke.org wrote: Robby Findler wrote at 07/10/2012 05:20 PM: On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flattmfl...@cs.utah.edu wrote: - mzlib [...] - mzscheme [...] I don't think these should be removed or deprecated, ever. I have lots of code that still refers to them --- I doubt that I'm alone --- and I think we should be able to support them. I agree that these should never be removed. I would not mind if they were marked in some way as these are here for legacy reasons. New code should use XYZ with specific pointers and helpful advice. I'm still using some mzlib in *new* code. Specifically, getpid, this-expression-source-directory, gethostname, and perhaps one or two other things. I could find other ways to do those things if I had to, but those definitions pop up when I search, and there's no glaring warning not to use them. All the useful contents in mzscheme and mzlib should really have an equivalent somewhere else, usually in racket/something, so that new code never needs to import old libraries. That would allow mzscheme and mzlib to be deprecated as legacy code. Personally I'd be okay with it being removed after sufficient warning, but I can see the argument for maintaining them indefinitely. If we ever get a distribution split up into separate packages, then developers could choose whether to install mzscheme and mzlib if they really [did/didn't] need them, and we'd get the best of both worlds. --Carl _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
At Tue, 10 Jul 2012 18:44:28 -0400, Neil Van Dyke wrote: I'm still using some mzlib in *new* code. Specifically, getpid, this-expression-source-directory, gethostname, and perhaps one or two other things. I could find other ways to do those things if I had to, but those definitions pop up when I search, and there's no glaring warning not to use them. Good point. We're looking through `mzlib''s bindings to find such functions that don't have equivalents elsewhere in the collects. We're planning to move these to appropriate libraries. For example, `gethostname' and `getpid' should probably go somewhere like `racket/os' (and probably be renamed to `get-hostname' and `get-pid'). Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
On this front, this-expression-source-directory is, for nearly all purposes, worse than define-runtime-path. Robby On Tue, Jul 10, 2012 at 5:54 PM, Vincent St-Amour stamo...@ccs.neu.edu wrote: At Tue, 10 Jul 2012 18:44:28 -0400, Neil Van Dyke wrote: I'm still using some mzlib in *new* code. Specifically, getpid, this-expression-source-directory, gethostname, and perhaps one or two other things. I could find other ways to do those things if I had to, but those definitions pop up when I search, and there's no glaring warning not to use them. Good point. We're looking through `mzlib''s bindings to find such functions that don't have equivalents elsewhere in the collects. We're planning to move these to appropriate libraries. For example, `gethostname' and `getpid' should probably go somewhere like `racket/os' (and probably be renamed to `get-hostname' and `get-pid'). Vincent _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
At Tue, 10 Jul 2012 16:20:16 -0500, Robby Findler wrote: On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa wrote: - defmacro in mzlib I'm skeptical that this one should be removed,. At a minimum, though, it could be better explained/discouraged in the docs for the hack that it is. Why do you want to keep this? Some will want `defmacro', maybe for porting old code. So, if we don't provide `defmacro', then others will waste time re-creating it and/or asking how to re-create it. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
Right, of course you're right. On Tue, Jul 10, 2012 at 7:32 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 10 Jul 2012 16:20:16 -0500, Robby Findler wrote: On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa wrote: - defmacro in mzlib I'm skeptical that this one should be removed,. At a minimum, though, it could be better explained/discouraged in the docs for the hack that it is. Why do you want to keep this? Some will want `defmacro', maybe for porting old code. So, if we don't provide `defmacro', then others will waste time re-creating it and/or asking how to re-create it. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
5 hours ago, Asumu Takikawa wrote: Recently, we've made some progress on getting rid of parts of our legacy codebase (e.g., mzlib/class100). Since a release is coming up, that is an opportunity to do more cleanup. Vincent and I have been brainstorming what other collections could be set on a 1-year deprecation removal notice. As long as you're trying to do something proper, I think that you should come up with a good mechanism for ensuring the eventual removal. Something like this: * Add some deprecation information that is used to specify a removal timeline: eg, a time that it will be very strongly discouraged from being used, and a time that it will be actually removed, and possibly some recommendation like code should not use it. A nice feature could be specifying that it will move to a planet package, with a reference to that package in the recommendation, and timeline dates indicating when the move will hapen. * This information can be in code or in info files or something like that. * The documentation could extract this information to be rendered nicely. * Have some ways to provide sufficient advance warnings for people. For example, when the strongly discouraged date has passed, a macro could throw up a log warning, some time after that it could throw an stderr warning. * Have a way to avoid forgetting the removal. Originally, I suggested throwing an error from a macro, but that's probably too aggresive for people who would want to keep using old distribution for a long time. So a more mild approach would be to have a test suite that fails after the expiration date, ensuring that it does get removed but not breaking up for people. - combinator-parser This library only has .txt documentaiton and looks bitrotted. There are no users of this collection as far as we know and it's unlikely to gain any (due to lack of documentation). - test-box-recovery A library for compatibility with the pre-v360 DrScheme format +1 - tex2page Undocumented and it's unclear how it's related to Racket AFAIK, Dorai is still maintaining that. Perhaps it could be moved into a planet package instead. There's a minor complication there in that it's code that is supposed to run in multiple systems, and he'll probably need someone to actually do the planet packaging and the occasional update for him... - mzlib Most of this library has been superceded and the rest should probably either be moved elsewhere (e.g., mzlib/control) or removed. - mzscheme This is a superceded, legacy language It does look impractical to remove them, but my guess is that it will be possible to do so in a much longer timeframe. It will definitely help to move the real code left in mzlib into racket/* so that existing uses can be updated too. Also, it would be nice to continuously upgrade files that use the `mzscheme' language. With packages, they could be put into a compat package, which would be a good additional hint for what they are. - defmacro in mzlib mzlib in general, but this one in particular because it is highly misleading for newcomers (who think it's a blessed macro facility). Has no real users in the core codebase (there are two requires in benchmarks but no uses) -1, I'll reply elsewhere. -- ((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] Deprecating collects
An hour and a half ago, Robby Findler wrote: On this front, this-expression-source-directory is, for nearly all purposes, worse than define-runtime-path. I think that there are some rare uses that can use `this-expression-source-directory'. Not for things that you depend on, but for code that actually wants to know where it is in the filesystem. For example, code that knows how to update itself, wants to package its own source tree, or wants to remove .git* files from itself. In such cases you don't want to add a . runtime path, because they're not uses that imply a dependency. But perhaps the difference is too subtle to be worth keeping. Or maybe there should be something like the runtime-path tool that doesn't add a depencency. -- ((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] Deprecating collects
If someone has a good reason to get rid of this-expression-source-directory, I'm mostly indifferent. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
50 minutes ago, Matthew Flatt wrote: Some will want `defmacro', maybe for porting old code. So, if we don't provide `defmacro', then others will waste time re-creating it and/or asking how to re-create it. +7. And given a plan for migrating code from mzlib/* to racket/*, I think that this should be moved too -- but the documentation should be very explicit about the bad sides of using it, much more than it does now. (It could also mention a brief note on how it guesses the context back since that makes the hack aspect very obvious.) Three concrete examples for it being very useful: 1. Porting old scheme or CL code, or even new code written by people who know only symbolic macros. In both cases it's better to have some way to do a quick job, and later on upgrade to proper macros rather than make it an all-or-nothing job (which in these cases will often end up on the nothing side). 2. Semi-related: some people will inevitably use defmacro because they have a vague intuition that it's obviously the most powerful system, so they'll continue using it. Having a defmacro in Racket is a very real way to say no, it's a weaker system that can be emulated. I know that this is a very high-level reason, but it is manifested in a real way by allowing these people to port/write code quickly and later on learn about proper macros. (This item is based on a *lot* of interactions I've had with many people on this subject.) 3. Another place where I find it useful (and also semi²-related), is teaching. I find it very useful to introduce macros as just sexpr functions since it corresponds to the simplified mental model that students use for writing interpreters, then see how that breaks, then show how the syntax type should grow from sexpr to sexpr+scope, which also makes it more natural to later see how it keeps growing to accomodate source information and more. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
This commit adds a bad dependency from the core to framework. Fixing it is probably not hard, but it leads to an obvious question: Why is this in racket instead of some new collection? 10 hours ago, jamesswa...@racket-lang.org wrote: b6f71ec James Swaine jamesswa...@racket-lang.org 2012-02-29 11:43 : | Add futures visualizer, improvements to futures logging : A collects/racket/future/private/constants.rkt A collects/racket/future/private/display.rkt A collects/racket/future/private/drawing-helpers.rkt A collects/racket/future/private/graph-drawing.rkt A collects/racket/future/private/gui-helpers.rkt A collects/racket/future/private/visualizer-data.rkt A collects/racket/future/private/visualizer-drawing.rkt A collects/racket/future/private/visualizer-gui.rkt A collects/racket/future/visualizer.rkt -- ((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] Need a clarification on the implementation of stream-map
No, I didn't write `racket/stream' -- Matthew did it based on the stream srfi. This came up not too long ago, and I sent a question about it here: http://lists.racket-lang.org/dev/archive/2012-June/009612.html Since there were no replies, I meant to remove it but didn't get to it. I'll push it out now. 6 hours ago, Daniel King wrote: Sorry, I accidentally sent this off the mailing list and accidentally switched emails. Eli, I don't see any trace of multiple valued `stream's in racket/stream. Can you confirm or deny their existence? On Tue, Jul 10, 2012 at 11:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Eli wrote racket/stream based on racket/sequence which I wrote. You'll have to ask him whether he added support for multiple-value sequences and how to get them. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
It is the future visualizer so I thought it belonged with the visualizer. No? Alternative suggestions welcome. Robby On Tue, Jul 10, 2012 at 9:34 PM, Eli Barzilay e...@barzilay.org wrote: This commit adds a bad dependency from the core to framework. Fixing it is probably not hard, but it leads to an obvious question: Why is this in racket instead of some new collection? 10 hours ago, jamesswa...@racket-lang.org wrote: b6f71ec James Swaine jamesswa...@racket-lang.org 2012-02-29 11:43 : | Add futures visualizer, improvements to futures logging : A collects/racket/future/private/constants.rkt A collects/racket/future/private/display.rkt A collects/racket/future/private/drawing-helpers.rkt A collects/racket/future/private/graph-drawing.rkt A collects/racket/future/private/gui-helpers.rkt A collects/racket/future/private/visualizer-data.rkt A collects/racket/future/private/visualizer-drawing.rkt A collects/racket/future/private/visualizer-gui.rkt A collects/racket/future/visualizer.rkt -- ((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] promise vs polym contracts
On Friday, Carl Eastlund wrote: From in-person conversation, what's really going on here is that Matthias is talking about some other, imaginary language, not Racket, where _any_ primitive operation other than promise? forces any promises in its arguments. In this language, promises are more like an implicit monad than a data structure. To make it more concrete in a possibly more obscure way, I think that he's talking about a world where you only need `lazy', not `delay'. (Since the only point of the latter is being able to distinguish a promise that forces to a promise.) To put it differently, you don't have to switch to the world where promises are forced implicitly (that's the r5rs blurb that I said many times that it should be removed since it's much more than just a footnote to a language), you just need a world where being a `promise?' is something that concerns only meta/introspective kind of code, as in Robby's followp. On Saturday, Matthias Felleisen wrote: The more general idea is that there is an alternative design space out there where you want 'boxes' that signal errors when touched by strict functions. You need these every time you want transparent transitions from one point in the computational spectrum to another. ;; --- And one more level up, I am thinking of selling Racket as a wide-spectrum programming language, the first one that introduces safe or transparent transitions properly. To combine both of these and my general wish for how the lazy language would evolve: it would be nice beyond words if there was some new implicit `#%value' macro wrapped around places that require a value. With that, an implementation of a lazy language would be trivial, together with all of the related similar-in-spirit languages. (To relate this to another recent thing -- having a no-value thing that doesn't leak out is too restrictive for some uses (as I need to write in the followup I promised), but a way to loosen that restriction so you can pass around no-values and avoid a damaging leak would be to make such a `#%value' check for them... But that's of course just vague hand-waving that would naively suffer from the same perfomance problems...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
10 minutes ago, Robby Findler wrote: It is the future visualizer so I thought it belonged with the visualizer. No? (You mean ... belonged with the futures, right?) Alternative suggestions welcome. I think that it fits well with other meta-analysis kind of tools like errortrace and the profiler, so a new toplevel collection seems to make perfect sense. I don't have a concrete suggestion better than future-visualizer though since I don't know what it does exactly. Maybe future-debugger or future-tracker or something like that? On Tue, Jul 10, 2012 at 9:34 PM, Eli Barzilay e...@barzilay.org wrote: This commit adds a bad dependency from the core to framework. Fixing it is probably not hard, but it leads to an obvious question: Why is this in racket instead of some new collection? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Robby Findler wrote: It is the future visualizer so I thought it belonged with the visualizer. No? (You mean ... belonged with the futures, right?) Right. :) Alternative suggestions welcome. I think that it fits well with other meta-analysis kind of tools like errortrace and the profiler, so a new toplevel collection seems to make perfect sense. I don't have a concrete suggestion better than future-visualizer though since I don't know what it does exactly. Maybe future-debugger or future-tracker or something like that? I think we have too many top-level collections and making a new one, especially with future- in the name seems like a step in the wrong direction. (visualizer is a better word than debugger or tracker for what it does, IMO, altho it has elements of those. But if you read the docs in the Guide about it, you should get some idea what it does.) Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
On Tue, Jul 10, 2012 at 10:51 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Robby Findler wrote: It is the future visualizer so I thought it belonged with the visualizer. No? (You mean ... belonged with the futures, right?) Right. :) Alternative suggestions welcome. I think that it fits well with other meta-analysis kind of tools like errortrace and the profiler, so a new toplevel collection seems to make perfect sense. I don't have a concrete suggestion better than future-visualizer though since I don't know what it does exactly. Maybe future-debugger or future-tracker or something like that? I think we have too many top-level collections and making a new one, especially with future- in the name seems like a step in the wrong direction. (visualizer is a better word than debugger or tracker for what it does, IMO, altho it has elements of those. But if you read the docs in the Guide about it, you should get some idea what it does.) Agreed, debugger and tracker don't really adequately describe it. Maybe future-profiler is another option, but maybe confusing since we already have profiler. (But I still think visualizer is best, IMHO). Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
An hour and a half ago, Robby Findler wrote: On Tue, Jul 10, 2012 at 10:41 PM, Eli Barzilay e...@barzilay.org wrote: 10 minutes ago, Robby Findler wrote: It is the future visualizer so I thought it belonged with the visualizer. No? (You mean ... belonged with the futures, right?) Right. :) Alternative suggestions welcome. I think that it fits well with other meta-analysis kind of tools like errortrace and the profiler, so a new toplevel collection seems to make perfect sense. I don't have a concrete suggestion better than future-visualizer though since I don't know what it does exactly. Maybe future-debugger or future-tracker or something like that? I think we have too many top-level collections and making a new one, especially with future- in the name seems like a step in the wrong direction. If more tools will be there, then it could be futute/something... Or maybe add a new tools collection for other similar things? But in any case, having a new toplevel collection seems much less of a problem than having a tool in racket/*. (visualizer is a better word than debugger or tracker for what it does, IMO, altho it has elements of those. But if you read the docs in the Guide about it, you should get some idea what it does.) An hour and a half ago, James Swaine wrote: Agreed, debugger and tracker don't really adequately describe it. Maybe future-profiler is another option, but maybe confusing since we already have profiler. (But I still think visualizer is best, IMHO). (I did say that I don't know what it's doing so I was blindly guessing...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24961: master branch updated
Yesterday, sa...@racket-lang.org wrote: 6bf1415 Sam Tobin-Hochstadt sa...@racket-lang.org 2012-07-06 12:13 : | Each typed module now defines a submodule named `type-decl`. | [...] Assuming that you want to allow people to write code with submodules, I think that a name like `#%type-decl' would be much better. -- ((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
