Re: [racket-dev] Mangaging `unstable` with packages
On Friday, Sam Tobin-Hochstadt wrote: # `unstable/list` - `remf`, `list-update` `list-set` `map/values`: move to `racket/list` - `group-by`: rename to `group`, add keyword argument `#:by` defaulting to `equal?`, move to `racket/list` All of these are used in the tree only by their authors, and almost all of them are used between zero and time. `remf' is the same as `filter-not'. `map/values' can be expressed in most cases more conveniently with `for/fold'. `group-by' is doing something weird -- see for example clojure's function by the same name that does something that looks more useful (IMO). Also, `group' sounds way too generic for something as specific as what it does. -- ((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] Mangaging `unstable` with packages
I also don't know what they are. They appear to have been added by Neil T 18 months ago. Neil? Sam On Jun 21, 2013 6:37 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I'm not completely clear on what latent-contracts are, but perhaps options should be being used there? Robby On Fri, Jun 21, 2013 at 5:17 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: The new package organization gives us a chance to re-asses the unstable collection. Going forward, I think the unstable collection should be used in the following ways: 1. If you build something that you think is general-purpose, but is only used in one package, put it in `unstable/foo`, but keep it inside that package. 2. If you either (a) want to use some other package's `unstable/foo` library, or (b) create such a library that's used across multiple packages, create a separate package called unstable-foo for it. It's perhaps worth saying why we still need unstable at all in the new regime. We might just create a new package for, say, parameter groups, and just add that as a dependency of plot. But that would ship a library in a useful location, and potentially commit us to that library and API for the future. So I think we should keep unstable around. With that said, I'd like to also propose moving the following out of unstable: # `unstable/list` - `remf`, `list-update` `list-set` `map/values`: move to `racket/list` - `group-by`: rename to `group`, add keyword argument `#:by` defaulting to `equal?`, move to `racket/list` - `extend`, `filter/values`: move back into Typed Racket - `list-prefix?`: move back into the web server - `map2`, `check-duplicate`, `*-common-prefix`: Delete # `unstable/parameter-group` This is used by both the image and plot libraries. Create a new top-level collection and package. # `unstable/latent-contract` Currently undocumented. Used by the image collection anyway. This needs to be fixed. That's it for things outside of the unstable package, which I'll tackle another time. Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Mangaging `unstable` with packages
On Mon, Jun 24, 2013 at 3:52 AM, Eli Barzilay e...@barzilay.org wrote: On Friday, Sam Tobin-Hochstadt wrote: # `unstable/list` - `remf`, `list-update` `list-set` `map/values`: move to `racket/list` - `group-by`: rename to `group`, add keyword argument `#:by` defaulting to `equal?`, move to `racket/list` All of these are used in the tree only by their authors, and almost all of them are used between zero and time. `remf' is the same as `filter-not'. This is false, as the example in the `remf` docs shows. `map/values' can be expressed in most cases more conveniently with `for/fold'. I've used `map/values`, and I'm not its author. Also, it's a function that I've seen requested for years. `group-by' is doing something weird -- see for example clojure's function by the same name that does something that looks more useful (IMO). Also, `group' sounds way too generic for something as specific as what it does. `group-by`, and my proposed `group`, is what Haskell provides. I don't find the Clojure version nearly as compelling, since it combines a map and a grouping operation. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Mangaging `unstable` with packages
A few minutes ago, Sam Tobin-Hochstadt wrote: On Mon, Jun 24, 2013 at 3:52 AM, Eli Barzilay e...@barzilay.org wrote: On Friday, Sam Tobin-Hochstadt wrote: # `unstable/list` - `remf`, `list-update` `list-set` `map/values`: move to `racket/list` - `group-by`: rename to `group`, add keyword argument `#:by` defaulting to `equal?`, move to `racket/list` All of these are used in the tree only by their authors, and almost all of them are used between zero and time. `remf' is the same as `filter-not'. This is false, as the example in the `remf` docs shows. s/same/almost the \1/ [We already went over this: I don't find the remove-first functionality too useful (I use (remove* (list x) l) *very* frequently), but with a function a `remf' that is not a `refm*' is even less useful and more surprising.] `map/values' can be expressed in most cases more conveniently with `for/fold'. I've used `map/values`, and I'm not its author. Also, it's a function that I've seen requested for years. (OK, sam added from carl; but you're still the only client in the tree.) `group-by' is doing something weird -- see for example clojure's function by the same name that does something that looks more useful (IMO). Also, `group' sounds way too generic for something as specific as what it does. `group-by`, and my proposed `group`, is what Haskell provides. I don't find the Clojure version nearly as compelling, since it combines a map and a grouping operation. Haskell does something more tame, and more predictable in the sense of splitting an ordered list. And yes, it looks like a good idea to have *that*. To be clear, the list-splitting functionality that I'd like to have: * Split a list to lists of length N (IIRC, clojure has some generalization where you specify an interval length + chunk length, so if you use 1,2 you get something like (x y z) = ((x y) (y z)).) * Split the list by some predicate over the elements, common use: take a list of strings and split it over \n items. Clojure has `partition-by' which is close, and the Haskell group-by can probably be used too (but possibly not conveniently enough to eliminate the need for what I want). (And as a sidenote, I agree with you that the clojure `group-by' is not too useful -- I think that this applies to many list functions that pretend that their input is a set.) -- ((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] Keywords
On Mon, Jun 17, 2013 at 5:09 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: p.s. On second thought, for structs you want two constructors: -- one that takes positional arguments -- one that takes keyword arguments My intent was that you could use both positional and keyword arguments at the same time, for each argument. This way, you may even avoid the new for `new', and use the procedure itself, i.e., with the same procedure or struct or class, you can simply write: (define (fish name weight) (list name weight)) and call it with: (fish #:name Nemo #:weight 700) or (fish Nemo 700) or (fish Nemo #:weight 700) and same for make-fish (for structs) and fish%. There would be no difference in the calling style between proc, struct and class. (Or maybe I misunderstood your point.) On Mon, Jun 17, 2013 at 5:28 PM, Neil Van Dyke n...@neilvandyke.orgwrote: I have used this in Python, and it is kinda neat and has its uses, but overall, I prefer the current way in Racket. One reason I prefer the current way in Racket is that, if every argument can be positional, then you have to keep this in mind when adding keyword arguments to a procedure that is used by other code: new arguments can only be added at the end of the list, even if that does not make the most sense for documentation purposes. Good point. Then one possibility is to allow to force an argument to be by-name only (I don't see a strong reason to allow to force an argument to be by-position only, except maybe to avoid bad proc-call habits, but not even sure). Another reason is that the keyword arguments restrict the syntax somewhat, so, when a mistaken extraneous sexp is where we'd expect a keyword, it is flagged as an error, rather than be considered a positional argument. Related to the previous reason, if the programmer is *intentionally* intermixing keyword arguments with positionals, such as (foo 37 #:x 41 74 #:a 34), that seems error-like that I wish they would get an error and change their ways. I agree, although less strongly than for the above point. I wouldn't mind to force calls to take positional arguments first, and have no more positional arguments after the first keyword. (it actually seems to be easier to implement this way too.) Though note that currently Racket does allow things like that: (define (foo y #:x x ) (list x y)) (foo #:x 3 1) ; - '(3 1) Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
Here's a simple demo for procedures if you want to try it out: https://gist.github.com/Metaxal/5851215 Laurent On Mon, Jun 24, 2013 at 4:54 PM, Laurent laurent.ors...@gmail.com wrote: On Mon, Jun 17, 2013 at 5:09 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: p.s. On second thought, for structs you want two constructors: -- one that takes positional arguments -- one that takes keyword arguments My intent was that you could use both positional and keyword arguments at the same time, for each argument. This way, you may even avoid the new for `new', and use the procedure itself, i.e., with the same procedure or struct or class, you can simply write: (define (fish name weight) (list name weight)) and call it with: (fish #:name Nemo #:weight 700) or (fish Nemo 700) or (fish Nemo #:weight 700) and same for make-fish (for structs) and fish%. There would be no difference in the calling style between proc, struct and class. (Or maybe I misunderstood your point.) On Mon, Jun 17, 2013 at 5:28 PM, Neil Van Dyke n...@neilvandyke.orgwrote: I have used this in Python, and it is kinda neat and has its uses, but overall, I prefer the current way in Racket. One reason I prefer the current way in Racket is that, if every argument can be positional, then you have to keep this in mind when adding keyword arguments to a procedure that is used by other code: new arguments can only be added at the end of the list, even if that does not make the most sense for documentation purposes. Good point. Then one possibility is to allow to force an argument to be by-name only (I don't see a strong reason to allow to force an argument to be by-position only, except maybe to avoid bad proc-call habits, but not even sure). Another reason is that the keyword arguments restrict the syntax somewhat, so, when a mistaken extraneous sexp is where we'd expect a keyword, it is flagged as an error, rather than be considered a positional argument. Related to the previous reason, if the programmer is *intentionally* intermixing keyword arguments with positionals, such as (foo 37 #:x 41 74 #:a 34), that seems error-like that I wish they would get an error and change their ways. I agree, although less strongly than for the above point. I wouldn't mind to force calls to take positional arguments first, and have no more positional arguments after the first keyword. (it actually seems to be easier to implement this way too.) Though note that currently Racket does allow things like that: (define (foo y #:x x ) (list x y)) (foo #:x 3 1) ; - '(3 1) Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] local-transformer-expand behavior
Hi all, Does anyone know what the behavior of (local-transformer-expand #'(define x 3) 'top-level null) should be? I'm not sure, but I expected something like what `local-expand` would do. Instead, I get an error like this: (define-syntax (m stx) (local-transformer-expand #'(define x 3) 'top-level null)) (m) ; readline-input:14:51: define: not allowed in an expression context ; in: (define x 3) ; [,bt for context] Am I just misuing the function? I also tried to wrap the quoted definition with a `let`, but then got errors saying `let-values` is unbound (which seems odd since it's a core form). Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] engine-kill from racket/engine
Hi all, I was trying to write an example for the racket/engine docs and stumbled on a case that seems to cause a deadlock. I'm curious if this is intentional or just accidental behavior. Here's the example: #lang racket (require racket/engine) (define e (engine (lambda (s) (sleep 5 (thread (lambda () (sleep 2) (engine-kill e))) (engine-run never-evt e) This will never terminate. If you comment out the fourth line, it will terminate. If you change `never-evt` to 4000 (or any other event that will become ready), it's also fine. What seems to be going on is that `engine-kill` does actually kill the thread underlying the engine. However, `engine-run` is `sync`ed on (1) the given event (2) the engine being done or (3) an exception being raised. Since `engine-kill` does not trigger any of those, the `sync` is blocked. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
