Re: [racket-dev] Keywords

2013-06-07 Thread Laurent
On Fri, Jun 7, 2013 at 1:42 AM, Matthew Flatt mfl...@cs.utah.edu 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

Re: [racket-dev] updated proposal for moving to packages

2013-06-07 Thread Matthew Flatt
At Thu, 6 Jun 2013 11:35:20 -0600, Jay McCarthy wrote: On Thu, Jun 6, 2013 at 9:33 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Since code in a package can synthesize a module reference dynamically, any static enforcement would have to be approximate, naturally (e.g., checks on all

Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

2013-06-07 Thread Greg Hendershott
I am *very* strongly in favor of this -- I'd rather have single-collection packages than multi-collection packages, if forced to choose. I'm very glad that you and Laurent have done the work here. I'd be happy to update all of my packages. Currently, of my 9 packages on pkg.racket-lang.org,

Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

2013-06-07 Thread Jay McCarthy
On Fri, Jun 7, 2013 at 2:49 PM, Greg Hendershott greghendersh...@gmail.com wrote: I am *very* strongly in favor of this -- I'd rather have single-collection packages than multi-collection packages, if forced to choose. I'm very glad that you and Laurent have done the work here. I'd be happy

Re: [racket-dev] PLaneT(2): Single vs multi-collection packages

2013-06-07 Thread Greg Hendershott
Thank you for the thorough explanation. Also, I'm having the duh moment I predicted. A collection may have modules in subdirs and still be just one collection. The use case for a multi-collection package is when you have collections A and B that you want to be packaged and installed together --

Re: [racket-dev] [plt] Push #26939: master branch updated

2013-06-07 Thread Eric Dobson
I don't think this is the right fix to the issue. A core issue (there may be more) is that calls to subtype during the dynamic extent of a call to subtype take the same current-seen list as is the current state of the outer subtype call. This works well when this is supposed to be part of the same