Re: [racket-dev] version 5.3.5 release, ready for testing
Here is some feedback. I did not read the book, so please ignore whatever is meaningless. Tested on (uname -a): Linux UX31A 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 13.04 Drracket starts, no problem. Games could run without major problem. Just some typos and minor comments: chapter2/source.rkt and chapter5/source.rkt : "you uessed it". -> "guessed" Chapter 5: guess game: quit with q does not close the frame (maybe normal?) and has the same behavior as =. ufo: The ufo "crashes" in the bottom of the frame. May be better if it "lands" properly? Check-syntax is activated, but does not handle non-pure text files, and thus displays an error message. Might be confusing for a beginner? Chapter 6: source.rkt: qiuckly -> quickly "BUG? << --" to be removed? Chapter 8: n does not start a new game Otherwise, looks like a lot of fun! I wish my teachers had used RoR for teaching us PLT Scheme ;) If anyone likes to play Dice of Doom, it has an improved version to which many hours of my PhD studentship got lost: http://www.gamedesign.jp/flash/dice/dice.html Laurent On Mon, Jun 17, 2013 at 2:41 AM, Matthias Felleisen wrote: > > A candidate release v5.3.5 is ready for testing at > >http://pre.racket-lang.org/5.3.5/ > > I have downloaded, installed, and played with the bundle on Mac OS X 10.8 > w/o a hitch. > > Could I ask for volunteers to check the bundle on Windows, older Macs, and > *nix boxes? > > Timeline: We'd like to release tomorrow or Tuesday. > > Thanks -- Matthias > > > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] version 5.3.5 release, ready for testing
Thanks Laurent and oev. I have pushed some repairs. -- Matthias On Jun 17, 2013, at 6:21 AM, Laurent wrote: > Here is some feedback. I did not read the book, so please ignore whatever is > meaningless. > > Tested on (uname -a): > Linux UX31A 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 > x86_64 x86_64 x86_64 GNU/Linux > Ubuntu 13.04 > > Drracket starts, no problem. Games could run without major problem. > > Just some typos and minor comments: > > chapter2/source.rkt and chapter5/source.rkt : > "you uessed it". -> "guessed" > > Chapter 5: > guess game: > quit with q does not close the frame (maybe normal?) and has the same > behavior as =. > > ufo: > The ufo "crashes" in the bottom of the frame. May be better if it "lands" > properly? > Check-syntax is activated, but does not handle non-pure text files, and thus > displays an error message. Might be confusing for a beginner? > > Chapter 6: > source.rkt: > qiuckly -> quickly > "BUG? << --" to be removed? > > Chapter 8: > n does not start a new game > > Otherwise, looks like a lot of fun! I wish my teachers had used RoR for > teaching us PLT Scheme ;) > > If anyone likes to play Dice of Doom, it has an improved version to which > many hours of my PhD studentship got lost: > http://www.gamedesign.jp/flash/dice/dice.html > > Laurent > > > On Mon, Jun 17, 2013 at 2:41 AM, Matthias Felleisen > wrote: > > A candidate release v5.3.5 is ready for testing at > >http://pre.racket-lang.org/5.3.5/ > > I have downloaded, installed, and played with the bundle on Mac OS X 10.8 w/o > a hitch. > > Could I ask for volunteers to check the bundle on Windows, older Macs, and > *nix boxes? > > Timeline: We'd like to release tomorrow or Tuesday. > > Thanks -- Matthias > > > > > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Generics
I have a long-running branch on github where I've been working on making the set datatype generic the way dictionaries are, and improving the generic system to support that effort. Some of the people here at Northeastern know about it, but I should probably make more people aware of the work. This is still a work in progress, it will be a while before it's ready for final review and push. https://github.com/carl-eastlund/racket/tree/generic-sets For sets, the main purpose has been to add gen:set and allow the set datatype to be extended. Along with that, I've added mutable sets and make-custom-set, akin to make-custom-hash, and made lists usable as sets based on equal? comparisons. I've made an effort to put a lot of methods in gen:set, rather than the bare minimum to make a set work. My goal is for an implementer to provide whatever subset of the operations is necessary or desirable for a given set representation, and have fallback implementations that will automatically be used for other methods. For example, a simple representation might implement only set-member? and set-add, leaving set-union to the default behavior using repeated set-add. A more clever representation, such as red-black tree sets, might have a custom efficient set-union operation. At first I encoded this pattern by having separate back-end methods for implementers to provide via gen:set, and wrapper functions that called set operations if present and used default implementations otherwise. But this is cumbersome to program, and probably other generics will want it. So I extended define-generics to take a #:fallbacks option. Now generic methods can be given a fallback implementation in terms of the other methods that will be used for any representations that do not provide a specific implementation. I have also added a #:extend option to define-generics, so a new generic method group can extend one or more others. If generic method group A extends B and C, then implementations of methods for A should include any definitions for the methods of B and C, and the new type will belong to all three of A, B, and C. This feature is more speculative than #:fallbacks; I don't have a use for it in sets, but I think it would be valuable if we make pervasive use of generics in the near future. It would be much more convenient to use generics with #:extend if structure properties supported "diamond-shaped" derivation graphs. That is, if property A derives B and C, and B and C each derive D, currently make-struct-type raises an error because an implementation of A results in multiple implementations of D. This prevents some natural patterns of related generics. It would be nice to have some way of disambiguating implementations to allow this, for instance if a struct type directly provides an implementation for property D, it overrides any derived from A, B, and C so that they can all coexist. Right now I'm working on the behavior of make-custom-set, which has raised some questions about the behavior of make-custom-hash. I think I'll save that discussion for a separate email in the near future, so as to keep to more or less one topic and not go sprawling on for pages. More pages, I mean. Anyway, I hope this is all stuff that looks good to people, because I've put a lot of work into it, but I'm open to feedback if I've taken a wrong turn somewhere. Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
Actually I realize I'd like something exactly like `instantiate'. If instantiate used keywords instead of bindings, and removing the `instantiate' word, we would then even have the exact same syntax for class instantiation and procedure call: (define nemo (fish% "Nemo" #:age 3)) ; instantiates `fish%' Of course this could be extended to structs. This would harmonize different calling mechanisms, as well as being more flexible. Wouldn't that be nice? Laurent On Fri, Jun 7, 2013 at 8:12 AM, Laurent wrote: > > > > On Fri, Jun 7, 2013 at 1:42 AM, Matthew Flatt wrote: > >> At Thu, 9 May 2013 16:22:54 +0200, Laurent wrote: >> > > I've always wondered why the syntax of keywords implied two elements: >> the >> > #:keyword and the identifier. >> > I find that quite heavy for procedure headers, and most of the time I >> use >> > the same symbol for the identifier and the keyword (and when I don't >> it's >> > because I'm simply lazy and use a shorter identifier). >> > >> > Is there a rationale somewhere for that? >> >> The rationale is to make function definitions have the same shape as >> function calls. >> > > I see what you mean, though I wouldn't make a strong case of it (maybe I'm > missing something). > > From time to time, I really feel frustrated by the current function header > style. > > What I'd really like, for the sake of flexibility / ease of use, is to > have no explicit keyword argument, but all arguments are implicit ones, so > that you can call a function by mixing by position and by name as you > like, > without having specified so in the function's header. > (Visual Basic[1] and Python[2] do something along these lines.) > > For example: > (define (foo x y [z 3] [t 4]) ) > > (foo 1 2 5) > (foo #:z 5 #:y 1 #:x 2) > (foo 1 #:t 6 #:y 3) > > (foo #:x 3) > Error: missing mandatory argument `y' > > (apply/kw f 2 #:y 3 '(5) '((t . 3))) > > In particular, one would then not have to worry about the order of the > optional arguments in the function definition. > > Headers would be also smaller, easier to read, and easier to write. > > Pushing a bit further: > (define (foo x y . rest) ) > would not accept keywords different from #:x and #:y, but > (define (foo x y . rest-by-pos . rest-by-name) ) > would receive a list of positional argument values, and a dictionary of > names and values, even if these names are not x or y. > > Laurent > [1] http://msdn.microsoft.com/en-us/library/51wfzyw0.aspx > [2] > http://www.diveintopython.net/power_of_introspection/optional_arguments.html > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
I like this idea a lot. -- Matthias On Jun 17, 2013, at 10:52 AM, Laurent wrote: > Actually I realize I'd like something exactly like `instantiate'. > If instantiate used keywords instead of bindings, and removing the > `instantiate' word, we would then even have the exact same syntax for class > instantiation and procedure call: > > (define nemo (fish% "Nemo" #:age 3)) ; instantiates `fish%' > > Of course this could be extended to structs. > > This would harmonize different calling mechanisms, as well as being more > flexible. > Wouldn't that be nice? > > Laurent > > > On Fri, Jun 7, 2013 at 8:12 AM, Laurent wrote: > > > > On Fri, Jun 7, 2013 at 1:42 AM, Matthew Flatt wrote: > At Thu, 9 May 2013 16:22:54 +0200, Laurent wrote: > > I've always wondered why the syntax of keywords implied two elements: the > > #:keyword and the identifier. > > I find that quite heavy for procedure headers, and most of the time I use > > the same symbol for the identifier and the keyword (and when I don't it's > > because I'm simply lazy and use a shorter identifier). > > > > Is there a rationale somewhere for that? > > The rationale is to make function definitions have the same shape as > function calls. > > I see what you mean, though I wouldn't make a strong case of it (maybe I'm > missing something). > > From time to time, I really feel frustrated by the current function header > style. > > What I'd really like, for the sake of flexibility / ease of use, is to > have no explicit keyword argument, but all arguments are implicit ones, so > that you can call a function by mixing by position and by name as you like, > without having specified so in the function's header. > (Visual Basic[1] and Python[2] do something along these lines.) > > For example: > (define (foo x y [z 3] [t 4]) ) > > (foo 1 2 5) > (foo #:z 5 #:y 1 #:x 2) > (foo 1 #:t 6 #:y 3) > > (foo #:x 3) > Error: missing mandatory argument `y' > > (apply/kw f 2 #:y 3 '(5) '((t . 3))) > > In particular, one would then not have to worry about the order of the > optional arguments in the function definition. > > Headers would be also smaller, easier to read, and easier to write. > > Pushing a bit further: > (define (foo x y . rest) ) > would not accept keywords different from #:x and #:y, but > (define (foo x y . rest-by-pos . rest-by-name) ) > would receive a list of positional argument values, and a dictionary of > names and values, even if these names are not x or y. > > Laurent > [1] http://msdn.microsoft.com/en-us/library/51wfzyw0.aspx > [2] > http://www.diveintopython.net/power_of_introspection/optional_arguments.html > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
p.s. On second thought, for structs you want two constructors: -- one that takes positional arguments -- one that takes keyword arguments but perhaps 'new' can play the role for both: (new fisht #:name "Nemo" #:weight 700) and (new fisht% #:name "Nemo" #:weight 700) might work. On Jun 17, 2013, at 10:52 AM, Laurent wrote: > Actually I realize I'd like something exactly like `instantiate'. > If instantiate used keywords instead of bindings, and removing the > `instantiate' word, we would then even have the exact same syntax for class > instantiation and procedure call: > > (define nemo (fish% "Nemo" #:age 3)) ; instantiates `fish%' > > Of course this could be extended to structs. > > This would harmonize different calling mechanisms, as well as being more > flexible. > Wouldn't that be nice? > > Laurent > > > On Fri, Jun 7, 2013 at 8:12 AM, Laurent wrote: > > > > On Fri, Jun 7, 2013 at 1:42 AM, Matthew Flatt wrote: > At Thu, 9 May 2013 16:22:54 +0200, Laurent wrote: > > I've always wondered why the syntax of keywords implied two elements: the > > #:keyword and the identifier. > > I find that quite heavy for procedure headers, and most of the time I use > > the same symbol for the identifier and the keyword (and when I don't it's > > because I'm simply lazy and use a shorter identifier). > > > > Is there a rationale somewhere for that? > > The rationale is to make function definitions have the same shape as > function calls. > > I see what you mean, though I wouldn't make a strong case of it (maybe I'm > missing something). > > From time to time, I really feel frustrated by the current function header > style. > > What I'd really like, for the sake of flexibility / ease of use, is to > have no explicit keyword argument, but all arguments are implicit ones, so > that you can call a function by mixing by position and by name as you like, > without having specified so in the function's header. > (Visual Basic[1] and Python[2] do something along these lines.) > > For example: > (define (foo x y [z 3] [t 4]) ) > > (foo 1 2 5) > (foo #:z 5 #:y 1 #:x 2) > (foo 1 #:t 6 #:y 3) > > (foo #:x 3) > Error: missing mandatory argument `y' > > (apply/kw f 2 #:y 3 '(5) '((t . 3))) > > In particular, one would then not have to worry about the order of the > optional arguments in the function definition. > > Headers would be also smaller, easier to read, and easier to write. > > Pushing a bit further: > (define (foo x y . rest) ) > would not accept keywords different from #:x and #:y, but > (define (foo x y . rest-by-pos . rest-by-name) ) > would receive a list of positional argument values, and a dictionary of > names and values, even if these names are not x or y. > > Laurent > [1] http://msdn.microsoft.com/en-us/library/51wfzyw0.aspx > [2] > http://www.diveintopython.net/power_of_introspection/optional_arguments.html > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
Laurent wrote at 06/07/2013 02:12 AM: What I'd really like, for the sake of flexibility / ease of use, is to have no explicit keyword argument, but all arguments are implicit ones, so that you can call a function by mixing by position and by name as you like, without having specified so in the function's header. (Visual Basic[1] and Python[2] do something along these lines.) 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. 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. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
I vote for this change too. I've been letting my planet packages sit in planet for too long now. This change provides a bit nicer upgrade path. :) Vincent St-Amour writes: > I vote for this change. > > I'm happy to change my packages (which make more sense as > single-collection packages anyway). > > If I understand correctly, this would also have the advantage of making > a lot of github repositories (including most of mine) installable as > packages automatically, no change required. That sounds like a huge win > to me. > > Vincent > > > > At Fri, 14 Jun 2013 07:07:26 -0700, > Matthew Flatt wrote: >> >> I think more people need to speak up on this question --- particularly >> authors of existing packages, since the current proposal necessitates >> an update to each existing package. >> >> The proposal is to make single-package collections the default: >> >> * If a directory used as a package has no "info.rkt" file, then it is >>treated as a single-collection package. >> >>The single collection's name is the same as the package name (which >>tends to be the directory name, but it depends on how you install >>the package). >> >> * If a directory used as a package has an "info.rkt" file, but >>"info.rkt" doesn't explicitly say that the package is >>multi-collection, then it's still a single-collection package. >> >>The "info.rkt" file might supply a name for the single collection, >>instead of leaving it to the package name; supplying a name would be >>a requirement for ring-0 packages. >> >> For each existing package, the author would need to add a line to the >> package's "info.rkt" to indicate that it is a multi-collection package >> (or change the layout to single-collection mode, with the caveat that >> the package won't work with v5.3.4). >> >> Any more votes for/against? >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
I'm still thinking that I'll keep my existing multi-collection packages as multi, to preserve compatibility with 5.3.4. Only because, although my packages don't have many users, I'll err on the side of their convenience. But if someone else did want to change from multi to single: 1. Philosophical: Wouldn't this be bad to do without renaming the package, since the spirit of the package system versioning is, never break backward compatibility? Or, is it acceptable, now, since this is technically still in beta? 2. Practical: Would `raco pkg update' handle such a multi->single transform? Or should packagers instruct users to (a) remove and (b) install? I'm asking in case it would help to have the answer(s) ready for doc or FAQ purposes. On Sat, Jun 15, 2013 at 11:19 AM, Matthew Flatt wrote: > At Fri, 14 Jun 2013 21:14:58 -0400, Greg Hendershott wrote: >> I just want to be clear what I need to do to >> keep compatibility with 5.3.4 for existing packages. If that means >> adding something to info.rkt to say, "yeah, I'm still multi", I may do >> that. > > Yes, that's exactly what will be required for a package to work with > both v5.3.4 and after the change: keep the package multi-collection, > and explicitly declare it as such by adding a line to "info.rkt". > > For the new "info.rkt" field, should it be > > (define multi-collection? #t) > > ? > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] release 5.3.5
Okay I see. I like the code style and conventions in HtDP, and I have read lots of books about design before I am here. I will try again when HtDP2e totally complete. Thanks On Mon, Jun 17, 2013 at 7:35 AM, Matthias Felleisen wrote: > > ROAR is something like a second step but we don't assume that you have > seen HtDP. > > HtDP is not about the examples but about [the] design [recipe] and as such > truly novel. It isn't about Racket either, otherwise we'd use Racket in the > book. As for 'interest', let freshmen judge. I'd prefer HtDP over ROAR any > day. > > Thanks for your interest. > > > > > On Jun 16, 2013, at 7:28 PM, WarGrey Gyoudmon Ju wrote: > > Sounds good to buy this book and I will do. > Will the book take the place of 'How to design program' in which examples > are quite simple and uninteresting even for the freshmen? > > My translate LOL with the intention of exploring the racket way. > Few resources could be the guider. > > > On Mon, Jun 17, 2013 at 5:42 AM, Matthias Felleisen > wrote: > >> >> Realm of Racket is not a translation of Land of Lisp, though it borrows >> ideas from the latter for about 1/2 of the book. The ROAR code is far more >> functional and GUI than LOL. -- Matthias >> >> >> >> >> On Jun 16, 2013, at 2:19 AM, WarGrey Gyoudmon Ju wrote: >> >> What a pity, I did not know this book before. >> I've been translating the source code of Land of Lisp using the racket >> way. >> I just finish the Grand Theft Wumpus game. >> >> >> On Sat, Jun 15, 2013 at 10:53 PM, Jay McCarthy wrote: >> >>> On Sat, Jun 15, 2013 at 8:50 AM, Greg Hendershott >>> wrote: >>> > 1. I'm really excited about the book, which I'll buy. >>> > >>> > 2. Issuing a release solely to ship code for a book: >>> > >>> > a. Seems unusual (to me), in general. >>> > >>> > b. Plus right now, message seems at odds with the new package >>> > manager and plan to move away from shipping monolithic collects? >>> > >>> > Admittedly that plan isn't in effect yet. But code for a book is a >>> > use case that today's package manager supports AFAICT. So why accrete >>> > another collection, is the reaction. >>> >>> The problem is that the book has "collects/realm" printed in it and >>> was designed simultaneously with the package system, so it wasn't >>> clear to make it a package, how to describe getting it, etc. >>> >>> Jay >>> >>> > p.s. I'm sharing an observation casually, not stating an objection >>> angrily. >>> > >>> > >>> > >>> > On Sat, Jun 15, 2013 at 9:46 AM, Matthias Felleisen >>> > wrote: >>> >> >>> >> We will release Racket v5.3.5 next week. The purpose of the >>> >> release is to include the Realm of Racket collection with the >>> >> v5.3.4 release, because the book is about to appear. >>> >> >>> >> The release will strictly be built from >>> >> >>> >> -- Racket v5.3.4 >>> >> -- collects/realm as currently found in git head >>> >> >>> >> We will __not__ make any other changes. >>> >> >>> >> Eli has worked out a process and will launch it asap. We will >>> >> conduct a recursive diff of all .rkt files and we will run >>> >> basic checks to ensure the integrity of the release bundle. >>> >> If you're willing to help with these checks, please stay tuned. >>> >> >>> >> >>> >> DRAFT RELEASE ANNOUNCEMENT: >>> >> >>> >> Racket version 5.3.5 is now available from >>> >> >>> >> http://racket-lang.org/ >>> >> >>> >> This is a special-purpose release to match the arrival of >>> >> "Realm of Racket" in bookstores. Racket v.5.3.5 adds a >>> >> single collection >>> >> >>> >> collects/realm/ >>> >> >>> >> to the v5.3.4 release. The new collection contains the source >>> >> code that readers of Realm may wish to use for experiments. >>> >> >>> >> >>> >> Comments welcome. -- Matthias >>> >> _ >>> >> Racket Developers list: >>> >> http://lists.racket-lang.org/dev >>> > _ >>> > Racket Developers list: >>> > http://lists.racket-lang.org/dev >>> >>> >>> >>> -- >>> Jay McCarthy >>> Assistant Professor / Brigham Young University >>> http://faculty.cs.byu.edu/~jay >>> >>> "The glory of God is Intelligence" - D&C 93 >>> _ >>> Racket Developers list: >>> http://lists.racket-lang.org/dev >>> >> >> _ >> Racket Developers list: >> http://lists.racket-lang.org/dev >> >> >> > > _ Racket Developers list: http://lists.racket-lang.org/dev
