Re: [racket-dev] Keywords
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-dev] Fwd: PLaneT(2): Single vs multi-collection packages
(post back to the mailing list...) On Thu, Jun 6, 2013 at 9:02 PM, Jay McCarthy wrote: > My goal is to have a large xrefed documentation site of all ring-0 > packages (we are close to this) so you can look up awesome or > slideshow-latex and then require it and have racket/DrRacket give you > a pop up that says, "Do you want to install package to get > this?" (I believe DrRacket does this now and we have xrepl that does > it too). Since ring-0 guarantees no conflicts, there is always a > unique answer to the require->package question. > (Btw, that sounds like a nice feature! I'd just worry a little about the size of the docs though, but then maybe you plan to have the docs can stay online?) In other words, my goal is to have only package authors ever concerned > with (a) their package names and (b) which package they are even > getting their modules from. UNLESS, you want to use ring-1 (untested) > or ring-2 (conflicting) packages---since using those rings is > inconvenient, it is incentivizes authors to remove conflicts and test > their code to get to ring-0. (In other words, I don't want any ring-1 > or 2 packages.) > I'm not sure how that poses problems with the use case above, but then in ring-0, you could easily ask for packages to be correctly named? I believe if you want to write a package of this quality, you should take time to name it correctly, and adding one line in the info.rkt file is no big deal (if ever really needed, which I expect to be rare). I don't really expect programmers of ring-0 to have bad habits, my main concern is with all the others, who certainly don't want to spend a lot of time understanding what to do to make a package. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26936: master branch updated
Good point. Might be an argument for a procedure-closure-contents-hash-code function. Of course, never mind that if you can forego memoization entirely. Carl Eastlund On Thu, Jun 6, 2013 at 7:46 PM, Vincent St-Amour wrote: > At Thu, 6 Jun 2013 18:39:57 -0400, > Carl Eastlund wrote: > > Also if you're going to memoize things, why are you using assoc rather > than > > a hash table? Or if at all possible, a weak hash table? > > I'm using `procedure-closure-contents-eq?' as the equality predicate. > AFAIK, there's no hash table for that. > > Vincent > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26936: master branch updated
Maybe. I'll see if I can think of a better solution.
Vincent
At Thu, 6 Jun 2013 17:35:50 -0500,
Robby Findler wrote:
>
> Can't we do better than a memo table?
>
> On Thursday, June 6, 2013, wrote:
>
> > stamourv has updated `master' from 5ea3a1ce6d to 6e8c9ed15a.
> > http://git.racket-lang.org/plt/5ea3a1ce6d..6e8c9ed15a
> >
> > =[ 2 Commits ]==
> > Directory summary:
> > 82.9% collects/racket/contract/private/
> > 17.0% collects/scribblings/reference/
> >
> > ~~
> >
> > d1df869 Vincent St-Amour >
> > 2013-06-06 18:02
> > :
> > | Document procedure-closure-contents-eq?.
> > :
> > M collects/scribblings/reference/procedures.scrbl | 5 +
> >
> > ~~
> >
> > 6e8c9ed Vincent St-Amour >
> > 2013-06-06 18:31
> > :
> > | Memoize wrapped case-> range contracts.
> > |
> > | Fixes failing contract tests.
> > :
> > M collects/racket/contract/private/arrow.rkt | 21 +++--
> >
> > =[ Overall Diff ]===
> >
> > collects/racket/contract/private/arrow.rkt
> > ~~
> > --- OLD/collects/racket/contract/private/arrow.rkt
> > +++ NEW/collects/racket/contract/private/arrow.rkt
> > @@ -1712,12 +1712,21 @@ v4 todo:
> >"the domain of"
> >#:swap? #t)))
> > dom-ctcs+case-nums)
> > -(map (λ (f)
> > - (define p (f rng-blame))
> > - (lambda args
> > - (with-continuation-mark
> > - contract-continuation-mark-key blame
> > - (apply p args
> > +(map (let ([memo '()])
> > + ;; to preserve
> > procedure-closure-contents-eq?ness of the
> > + ;; wrapped procedures, memoize with f
> > as the key.
> > + (λ (f)
> > + (define target
> > + (assoc f memo
> > procedure-closure-contents-eq?))
> > + (if target
> > + (cdr target)
> > + (let* ([p (f rng-blame)]
> > +[new (lambda args
> > +
> > (with-continuation-mark
> > +
> > contract-continuation-mark-key blame
> > +(apply p args)))])
> > + (set! memo (cons (cons f new)
> > memo))
> > + new
> > rng-ctcs)))
> >(define (chk val mtd?)
> > (cond
> >
> > collects/scribblings/reference/procedures.scrbl
> > ~~~
> > --- OLD/collects/scribblings/reference/procedures.scrbl
> > +++ NEW/collects/scribblings/reference/procedures.scrbl
> > @@ -88,6 +88,11 @@ to the wrong number of arguments, the resulting error
> > hides the first
> > argument as if the procedure had been compiled with the
> > @indexed-racket['method-arity-error] syntax property.}
> >
> > +@defproc[(procedure-closure-contents-eq? [proc1 procedure?]
> > + [proc2 procedure?]) boolean?]{
> > +Compares the contents of the closures of @racket[proc1] and @racket[proc2]
> > +for equality by comparing closure elements pointwise using @racket[eq?]}
> > +
> > @;
> > @section{Keywords and Arity}
> >
> >
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26936: master branch updated
At Thu, 6 Jun 2013 18:39:57 -0400, Carl Eastlund wrote: > Also if you're going to memoize things, why are you using assoc rather than > a hash table? Or if at all possible, a weak hash table? I'm using `procedure-closure-contents-eq?' as the equality predicate. AFAIK, there's no hash table for that. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
At Thu, 9 May 2013 16:22:54 +0200, Laurent wrote: > On Mon, May 6, 2013 at 2:52 PM, Matthew Flatt wrote: > > > Anything is open for discussion, but speaking for myself, I'm not > > interested in revisiting keyword syntax or case sensitivity. > > > > 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. For example, in (define (f x) ) the `(f x)' imitates the shape of a call, which has formal-argument variables replaced with actual-argument expressions: (f 5) Similarly, in (define (f x #:mode m) ) the `(f x #:mode m)' reflects the shape of a call (f 5 #:mode 'fast) > Would it be a bad idea for Racket2 to consider that keyword identifiers are > the same as the keyword without the `#:' ? I agree that it sometimes feels redundant to write both a keyword and an identifier in a function's formal arguments, since they're often spelled the same way. I can only say that I've tried things that way, and I prefer the current way (so, I think I'd vote to keep it as-is). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] patch to enable no-sidebar option in scribble
At Tue, 4 Jun 2013 18:55:51 -0400, Sean McBeth wrote:
> I'm not familiar with the ins and outs of Scribble, but it seems you could
> add to the scribble-style.css file:
> .tocsub{display:none;}
True, but I think the 'no-sidebar style property is a fine addition.
To me, the table of contents is the one that has sometimes seemed
redundant, which is why 'no-toc style property exists. I can believe
that 'no-sidebar is also useful, though.
I've pushed the patch. Thanks!
> On Tue, Jun 4, 2013 at 6:48 PM, Andrei Mikhailov wrote:
>
> > Dear developers,
> >
> > Here is a bug report with a proposed patch.
> >
> > The HTML output of the scribble includes the "on this page" sidebar.
> > Some people do not like this sidebar, because it seems to duplicate the
> > table of contents.
> > However, it seems that there is no style option to remove it.
> >
> > We propose the patch which would introduce the new style symbol
> > 'no-sidebar.
> > As a style for the main part of a document, this would cause the HTML
> > output to not include an ``on this page'' margin box.
> > See the attached patch file
> >
> > Andrei
> >
> > _
> > 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] [plt] Push #26936: master branch updated
Also if you're going to memoize things, why are you using assoc rather than
a hash table? Or if at all possible, a weak hash table?
Carl Eastlund
On Thu, Jun 6, 2013 at 6:35 PM, Robby Findler
wrote:
> Can't we do better than a memo table?
>
>
> On Thursday, June 6, 2013, wrote:
>
>> stamourv has updated `master' from 5ea3a1ce6d to 6e8c9ed15a.
>> http://git.racket-lang.org/plt/5ea3a1ce6d..6e8c9ed15a
>>
>> =[ 2 Commits ]==
>> Directory summary:
>> 82.9% collects/racket/contract/private/
>> 17.0% collects/scribblings/reference/
>>
>> ~~
>>
>> d1df869 Vincent St-Amour 2013-06-06 18:02
>> :
>> | Document procedure-closure-contents-eq?.
>> :
>> M collects/scribblings/reference/procedures.scrbl | 5 +
>>
>> ~~
>>
>> 6e8c9ed Vincent St-Amour 2013-06-06 18:31
>> :
>> | Memoize wrapped case-> range contracts.
>> |
>> | Fixes failing contract tests.
>> :
>> M collects/racket/contract/private/arrow.rkt | 21 +++--
>>
>> =[ Overall Diff ]===
>>
>> collects/racket/contract/private/arrow.rkt
>> ~~
>> --- OLD/collects/racket/contract/private/arrow.rkt
>> +++ NEW/collects/racket/contract/private/arrow.rkt
>> @@ -1712,12 +1712,21 @@ v4 todo:
>>"the domain of"
>>#:swap? #t)))
>> dom-ctcs+case-nums)
>> -(map (λ (f)
>> - (define p (f rng-blame))
>> - (lambda args
>> - (with-continuation-mark
>> - contract-continuation-mark-key
>> blame
>> - (apply p args
>> +(map (let ([memo '()])
>> + ;; to preserve
>> procedure-closure-contents-eq?ness of the
>> + ;; wrapped procedures, memoize with f
>> as the key.
>> + (λ (f)
>> + (define target
>> + (assoc f memo
>> procedure-closure-contents-eq?))
>> + (if target
>> + (cdr target)
>> + (let* ([p (f rng-blame)]
>> +[new (lambda args
>> +
>> (with-continuation-mark
>> +
>> contract-continuation-mark-key blame
>> +(apply p
>> args)))])
>> + (set! memo (cons (cons f new)
>> memo))
>> + new
>> rng-ctcs)))
>>(define (chk val mtd?)
>> (cond
>>
>> collects/scribblings/reference/procedures.scrbl
>> ~~~
>> --- OLD/collects/scribblings/reference/procedures.scrbl
>> +++ NEW/collects/scribblings/reference/procedures.scrbl
>> @@ -88,6 +88,11 @@ to the wrong number of arguments, the resulting error
>> hides the first
>> argument as if the procedure had been compiled with the
>> @indexed-racket['method-arity-error] syntax property.}
>>
>> +@defproc[(procedure-closure-contents-eq? [proc1 procedure?]
>> + [proc2 procedure?]) boolean?]{
>> +Compares the contents of the closures of @racket[proc1] and
>> @racket[proc2]
>> +for equality by comparing closure elements pointwise using @racket[eq?]}
>> +
>> @;
>> @section{Keywords and Arity}
>>
>>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26936: master branch updated
Can't we do better than a memo table?
On Thursday, June 6, 2013, wrote:
> stamourv has updated `master' from 5ea3a1ce6d to 6e8c9ed15a.
> http://git.racket-lang.org/plt/5ea3a1ce6d..6e8c9ed15a
>
> =[ 2 Commits ]==
> Directory summary:
> 82.9% collects/racket/contract/private/
> 17.0% collects/scribblings/reference/
>
> ~~
>
> d1df869 Vincent St-Amour >
> 2013-06-06 18:02
> :
> | Document procedure-closure-contents-eq?.
> :
> M collects/scribblings/reference/procedures.scrbl | 5 +
>
> ~~
>
> 6e8c9ed Vincent St-Amour >
> 2013-06-06 18:31
> :
> | Memoize wrapped case-> range contracts.
> |
> | Fixes failing contract tests.
> :
> M collects/racket/contract/private/arrow.rkt | 21 +++--
>
> =[ Overall Diff ]===
>
> collects/racket/contract/private/arrow.rkt
> ~~
> --- OLD/collects/racket/contract/private/arrow.rkt
> +++ NEW/collects/racket/contract/private/arrow.rkt
> @@ -1712,12 +1712,21 @@ v4 todo:
>"the domain of"
>#:swap? #t)))
> dom-ctcs+case-nums)
> -(map (λ (f)
> - (define p (f rng-blame))
> - (lambda args
> - (with-continuation-mark
> - contract-continuation-mark-key blame
> - (apply p args
> +(map (let ([memo '()])
> + ;; to preserve
> procedure-closure-contents-eq?ness of the
> + ;; wrapped procedures, memoize with f
> as the key.
> + (λ (f)
> + (define target
> + (assoc f memo
> procedure-closure-contents-eq?))
> + (if target
> + (cdr target)
> + (let* ([p (f rng-blame)]
> +[new (lambda args
> +
> (with-continuation-mark
> +
> contract-continuation-mark-key blame
> +(apply p args)))])
> + (set! memo (cons (cons f new)
> memo))
> + new
> rng-ctcs)))
>(define (chk val mtd?)
> (cond
>
> collects/scribblings/reference/procedures.scrbl
> ~~~
> --- OLD/collects/scribblings/reference/procedures.scrbl
> +++ NEW/collects/scribblings/reference/procedures.scrbl
> @@ -88,6 +88,11 @@ to the wrong number of arguments, the resulting error
> hides the first
> argument as if the procedure had been compiled with the
> @indexed-racket['method-arity-error] syntax property.}
>
> +@defproc[(procedure-closure-contents-eq? [proc1 procedure?]
> + [proc2 procedure?]) boolean?]{
> +Compares the contents of the closures of @racket[proc1] and @racket[proc2]
> +for equality by comparing closure elements pointwise using @racket[eq?]}
> +
> @;
> @section{Keywords and Arity}
>
>
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Thu, Jun 6, 2013 at 12:31 PM, Laurent wrote: > > > > On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy wrote: >> >> On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt >> wrote: >> > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt >> > wrote: >> >> >> >> >> >>> What I'd like is to have single-collection being the default [...] >> >>> >> >>> So here is a demo patch attached to precise what I mean (without >> >>> test, would have taken me way too much time). Because it considers >> >>> that single-collections are the default, it is backward incompatible. >> >>> If info.rkt exists, it looks for 'multi-collection, and otherwise >> >>> looks for the 'collection-name string. >> >> >> >> I could go along with this, as long as (most?) everyone agrees, and as >> >> long as package authors are willing to update existing packages. >> > >> > 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. >> >> The main problem with this is that it brings in internal linking where >> code directly refers to other packages (implementations) and not >> modules (interfaces) as the default. This means we will see code like >> (require jays-awesome-data-structure) rather than (require >> data/awesome). I think this is bad because it makes it harder to deal >> with forking, maintainers abandoning their code, splitting packages >> into packages that just depend on 'jays-awesome-data-structure, rather >> than implementing it internally, etc. Obviously you can still deal >> with those things, but if the path of evolution we imagine starts off >> with single-package-with-package/collection-name-shared, then most >> packaged collections will have a package as their name. > > > Ok, I see your point. > Let me try to make a use case here: > User A writes package P on Github at A/P. > A creates a PLaneT package also named P. > User B forks P to B/P. > Since the package name P is already taken, you expect B to name his > package B-P. > (But I think you make this point sufficiently clear in the docs that this > should be very seldom.) > > So on installation, you have a collection name B-P, which is bad, > because you cannot replace A's P directly by B's P, simply by > uninstalling A's and installing B's. > > Now, the thing is you'd like B's collection to be name P also, right? > (which means only one could be installed at the same time, otherwise we > get back to the same problem, whatever the option we choose.) > > Now if we really want to have P as the default collection name for B's P, > we could also probably use B's Github repo name. Is it retrievable from > the downloaded package? > We would then use this if available, or the package/directory name > otherwise (I guess non-repo installations will be rare anyway). > > But then people would still write > $ raco pkg install > but would then need to write > (require awesome) > > which is, in most cases, quite counter-intuitive: you'd need to state it > clearly in the docs of the package, but you would still have "dyslexic" > users > asking why it doesn't work (like I have with you, btw, with > slideshow-latex). > And this will probably occur much more often than the case above, > because you have many more users of packages than developers, and the > default should be intuitive for the largest part. You are correct that I see the separation of package-name and code-to-require as a big feature. You also correct that right now this can be a bit painful where it's not clear how they are connected. However, I see that as a consequence of where we are in development. My goal is to have a large xrefed documentation site of all ring-0 packages (we are close to this) so you can look up awesome or slideshow-latex and then require it and have racket/DrRacket give you a pop up that says, "Do you want to install package to get this?" (I believe DrRacket does this now and we have xrepl that does it too). Since ring-0 guarantees no conflicts, there is always a unique answer to the require->package question. In other words, my goal is to have only package authors ever concerned with (a) their package names and (b) which package they are even getting their modules from. UNLESS, you want to use ring-1 (untested) or ring-2 (conflicting) packages---since using those rings is inconvenient, it is incentivizes authors to remove conflicts and test their code to get to ring-0. (In other words, I don't want any ring-1 or 2 packages.) Jay -- 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
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Can't this be alleviated by the guidance on naming that the docs already provide? Sam On Jun 6, 2013 2:30 PM, "Jay McCarthy" wrote: > On Thu, Jun 6, 2013 at 12:03 PM, Sam Tobin-Hochstadt > wrote: > > On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy > 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. > >> > >> The main problem with this is that it brings in internal linking where > >> code directly refers to other packages (implementations) and not > >> modules (interfaces) as the default. This means we will see code like > >> (require jays-awesome-data-structure) rather than (require > >> data/awesome). I think this is bad because it makes it harder to deal > >> with forking, maintainers abandoning their code, splitting packages > >> into packages that just depend on 'jays-awesome-data-structure, rather > >> than implementing it internally, etc. Obviously you can still deal > >> with those things, but if the path of evolution we imagine starts off > >> with single-package-with-package/collection-name-shared, then most > >> packaged collections will have a package as their name. > > > > First, I don't see why single-collection packages make things harder > > to deal with re-implementing a package. Imagine that I make > > `disassemble` a single-collection package, and someone depends on it, > > and then I abandon my code. You can easily create a new package that > > ships that collection. I think that places the burden correctly -- > > it's easy to create packages initially, and handling abandoned > > packages takes a little more work. In JavaScript, where there's a > > flat namespace, this works -- the Zepto library just provides the same > > names as jQuery, even though they're different implementations and not > > generic names. > > The problem is that if you use the name "samths-disassemble" then even > in twenty years, my implementation uses the collection > "samths-disassemble" and not "disassemble". > > Jay > > > -- > 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
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
What if the differentiation between User A and User B's Package P were encoded in the version number, instead of the name. Semantically, that's what we're dealing with, two different versions of the same package. Directly after a fork, the packages would be Package P, version A.1.15, and Package P, version B.0.1; On Thu, Jun 6, 2013 at 2:31 PM, Laurent wrote: > > > > On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy wrote: > >> On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt >> wrote: >> > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt >> wrote: >> >> >> >> >> >>> What I'd like is to have single-collection being the default [...] >> >>> >> >>> So here is a demo patch attached to precise what I mean (without >> >>> test, would have taken me way too much time). Because it considers >> >>> that single-collections are the default, it is backward incompatible. >> >>> If info.rkt exists, it looks for 'multi-collection, and otherwise >> >>> looks for the 'collection-name string. >> >> >> >> I could go along with this, as long as (most?) everyone agrees, and as >> >> long as package authors are willing to update existing packages. >> >> > >> > 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. >> >> The main problem with this is that it brings in internal linking where >> code directly refers to other packages (implementations) and not >> modules (interfaces) as the default. This means we will see code like >> (require jays-awesome-data-structure) rather than (require >> data/awesome). I think this is bad because it makes it harder to deal >> with forking, maintainers abandoning their code, splitting packages >> into packages that just depend on 'jays-awesome-data-structure, rather >> than implementing it internally, etc. Obviously you can still deal >> with those things, but if the path of evolution we imagine starts off >> with single-package-with-package/collection-name-shared, then most >> packaged collections will have a package as their name. >> > > Ok, I see your point. > Let me try to make a use case here: > User A writes package P on Github at A/P. > A creates a PLaneT package also named P. > User B forks P to B/P. > Since the package name P is already taken, you expect B to name his > package B-P. > (But I think you make this point sufficiently clear in the docs that this > should be very seldom.) > > So on installation, you have a collection name B-P, which is bad, > because you cannot replace A's P directly by B's P, simply by > uninstalling A's and installing B's. > > Now, the thing is you'd like B's collection to be name P also, right? > (which means only one could be installed at the same time, otherwise we > get back to the same problem, whatever the option we choose.) > > Now if we really want to have P as the default collection name for B's P, > we could also probably use B's Github repo name. Is it retrievable from > the downloaded package? > We would then use this if available, or the package/directory name > otherwise (I guess non-repo installations will be rare anyway). > > But then people would still write > $ raco pkg install > but would then need to write > (require awesome) > > which is, in most cases, quite counter-intuitive: you'd need to state it > clearly in the docs of the package, but you would still have "dyslexic" > users > asking why it doesn't work (like I have with you, btw, with > slideshow-latex). > And this will probably occur much more often than the case above, > because you have many more users of packages than developers, and the > default should be intuitive for the largest part. > > Laurent > > > > _ > 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
On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy wrote: > On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt > wrote: > > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt > wrote: > >> > >> > >>> What I'd like is to have single-collection being the default [...] > >>> > >>> So here is a demo patch attached to precise what I mean (without > >>> test, would have taken me way too much time). Because it considers > >>> that single-collections are the default, it is backward incompatible. > >>> If info.rkt exists, it looks for 'multi-collection, and otherwise > >>> looks for the 'collection-name string. > >> > >> I could go along with this, as long as (most?) everyone agrees, and as > >> long as package authors are willing to update existing packages. > > > > 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. > > The main problem with this is that it brings in internal linking where > code directly refers to other packages (implementations) and not > modules (interfaces) as the default. This means we will see code like > (require jays-awesome-data-structure) rather than (require > data/awesome). I think this is bad because it makes it harder to deal > with forking, maintainers abandoning their code, splitting packages > into packages that just depend on 'jays-awesome-data-structure, rather > than implementing it internally, etc. Obviously you can still deal > with those things, but if the path of evolution we imagine starts off > with single-package-with-package/collection-name-shared, then most > packaged collections will have a package as their name. > Ok, I see your point. Let me try to make a use case here: User A writes package P on Github at A/P. A creates a PLaneT package also named P. User B forks P to B/P. Since the package name P is already taken, you expect B to name his package B-P. (But I think you make this point sufficiently clear in the docs that this should be very seldom.) So on installation, you have a collection name B-P, which is bad, because you cannot replace A's P directly by B's P, simply by uninstalling A's and installing B's. Now, the thing is you'd like B's collection to be name P also, right? (which means only one could be installed at the same time, otherwise we get back to the same problem, whatever the option we choose.) Now if we really want to have P as the default collection name for B's P, we could also probably use B's Github repo name. Is it retrievable from the downloaded package? We would then use this if available, or the package/directory name otherwise (I guess non-repo installations will be rare anyway). But then people would still write $ raco pkg install but would then need to write (require awesome) which is, in most cases, quite counter-intuitive: you'd need to state it clearly in the docs of the package, but you would still have "dyslexic" users asking why it doesn't work (like I have with you, btw, with slideshow-latex). And this will probably occur much more often than the case above, because you have many more users of packages than developers, and the default should be intuitive for the largest part. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Thu, Jun 6, 2013 at 12:03 PM, Sam Tobin-Hochstadt wrote: > On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy 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. >> >> The main problem with this is that it brings in internal linking where >> code directly refers to other packages (implementations) and not >> modules (interfaces) as the default. This means we will see code like >> (require jays-awesome-data-structure) rather than (require >> data/awesome). I think this is bad because it makes it harder to deal >> with forking, maintainers abandoning their code, splitting packages >> into packages that just depend on 'jays-awesome-data-structure, rather >> than implementing it internally, etc. Obviously you can still deal >> with those things, but if the path of evolution we imagine starts off >> with single-package-with-package/collection-name-shared, then most >> packaged collections will have a package as their name. > > First, I don't see why single-collection packages make things harder > to deal with re-implementing a package. Imagine that I make > `disassemble` a single-collection package, and someone depends on it, > and then I abandon my code. You can easily create a new package that > ships that collection. I think that places the burden correctly -- > it's easy to create packages initially, and handling abandoned > packages takes a little more work. In JavaScript, where there's a > flat namespace, this works -- the Zepto library just provides the same > names as jQuery, even though they're different implementations and not > generic names. The problem is that if you use the name "samths-disassemble" then even in twenty years, my implementation uses the collection "samths-disassemble" and not "disassemble". Jay -- 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
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy 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. > > The main problem with this is that it brings in internal linking where > code directly refers to other packages (implementations) and not > modules (interfaces) as the default. This means we will see code like > (require jays-awesome-data-structure) rather than (require > data/awesome). I think this is bad because it makes it harder to deal > with forking, maintainers abandoning their code, splitting packages > into packages that just depend on 'jays-awesome-data-structure, rather > than implementing it internally, etc. Obviously you can still deal > with those things, but if the path of evolution we imagine starts off > with single-package-with-package/collection-name-shared, then most > packaged collections will have a package as their name. First, I don't see why single-collection packages make things harder to deal with re-implementing a package. Imagine that I make `disassemble` a single-collection package, and someone depends on it, and then I abandon my code. You can easily create a new package that ships that collection. I think that places the burden correctly -- it's easy to create packages initially, and handling abandoned packages takes a little more work. In JavaScript, where there's a flat namespace, this works -- the Zepto library just provides the same names as jQuery, even though they're different implementations and not generic names. Second, I think this is already happening. Almost every package on `pkg.racket-lang.org` provides a new collection which is the primary code for the package, and which is named the same as the package. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt wrote: > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt wrote: >> >> >>> What I'd like is to have single-collection being the default [...] >>> >>> So here is a demo patch attached to precise what I mean (without >>> test, would have taken me way too much time). Because it considers >>> that single-collections are the default, it is backward incompatible. >>> If info.rkt exists, it looks for 'multi-collection, and otherwise >>> looks for the 'collection-name string. >> >> I could go along with this, as long as (most?) everyone agrees, and as >> long as package authors are willing to update existing packages. > > 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. The main problem with this is that it brings in internal linking where code directly refers to other packages (implementations) and not modules (interfaces) as the default. This means we will see code like (require jays-awesome-data-structure) rather than (require data/awesome). I think this is bad because it makes it harder to deal with forking, maintainers abandoning their code, splitting packages into packages that just depend on 'jays-awesome-data-structure, rather than implementing it internally, etc. Obviously you can still deal with those things, but if the path of evolution we imagine starts off with single-package-with-package/collection-name-shared, then most packaged collections will have a package as their name. Jay -- 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
Re: [racket-dev] updated proposal for moving to packages
On Thu, Jun 6, 2013 at 9:33 AM, Matthew Flatt wrote: > At Thu, 6 Jun 2013 10:00:56 -0400, Sam Tobin-Hochstadt wrote: >> > When we have a small core, then there should be >> > practically no packages without explicit dependencies --- when a >> > package's dependencies are specified accurately, at least. >> >> Is it possible to enforce, either in the package system or in DrDr or >> somewhere else, that dependencies are specified accurately? > > I don't think we can enforce it precisely, but I think we can test it > reasonably well. > > The simplest mechanism for testing dependencies is to just install the > package on a clean core and run some unit tests. I think that's > probably good enough for a while. Using built or binary packages for > dependencies makes the check much faster than it would be purely from > source. > > 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 `require's). Approximate checks would be useful, and I > don't think anyone has implemented them, yet. > > Complete enforcement would require some sort of dynamic check to > constrain access from code from a given package. That seems tricky at > best, and it's probably more than we need in practice. Matthew and I also once talked about have raco (make|setup) know about dependencies and signal a failure on a require outside the dependencies set. Is that still imaginable? Jay -- 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
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
At Thu, 6 Jun 2013 10:17:28 -0400, Sam Tobin-Hochstadt wrote: > > If we go that way, then I'd characterize a single-collection package > > without 'single-collection' in "info.rkt" as a low-quality package, but > > a low-quality package is a fine starting point for a high-quality > > package. > > Would this characterization be something reflected in any of the > software, or just a recommendation we make to packagers? Mostly a recommendation, but it might correspond to a software-enforced constraint on ring-0 packages (for which DrDr runs tests). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] updated proposal for moving to packages
At Thu, 6 Jun 2013 10:00:56 -0400, Sam Tobin-Hochstadt wrote: > > When we have a small core, then there should be > > practically no packages without explicit dependencies --- when a > > package's dependencies are specified accurately, at least. > > Is it possible to enforce, either in the package system or in DrDr or > somewhere else, that dependencies are specified accurately? I don't think we can enforce it precisely, but I think we can test it reasonably well. The simplest mechanism for testing dependencies is to just install the package on a clean core and run some unit tests. I think that's probably good enough for a while. Using built or binary packages for dependencies makes the check much faster than it would be purely from source. 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 `require's). Approximate checks would be useful, and I don't think anyone has implemented them, yet. Complete enforcement would require some sort of dynamic check to constrain access from code from a given package. That seems tricky at best, and it's probably more than we need in practice. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
> If info.rkt does not exist, it creates it and gives the 'collection-name > > the name of the package by default. > > That doesn't seem like a good idea to me. As you've noted, there can be > problems with writing extra files. The collection name could be instead > computed in `pkg-single-collection', which would treat the absence of > an "info.rkt" to mean single-collection mode, right? > > > Some calls to `pkg-single-collection' would need to change to pass in > a package name to use instead of the `dir' name, since the `dir' > argument is sometimes a temporary directory that is used to stage a > package. That's an easy change. > If the original package/directory name can be retrieved at any time, then yes, it's a much better idea (actually I had started this way, but didn't know how to retrieve the name at any time). Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt wrote: > > >> What I'd like is to have single-collection being the default [...] >> >> So here is a demo patch attached to precise what I mean (without >> test, would have taken me way too much time). Because it considers >> that single-collections are the default, it is backward incompatible. >> If info.rkt exists, it looks for 'multi-collection, and otherwise >> looks for the 'collection-name string. > > I could go along with this, as long as (most?) everyone agrees, and as > long as package authors are willing to update existing packages. 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, 8 are single collection, and 1 splices into the existing `data` collection (and has a second collection to work around a now-fixed limitation. In the interests of data, I looked at all of the packages on pkg.racket-lang.org marked as recently updated (6 of them) as well as the first 10 in alphabetical order. Of these, all but 3 have a single collection, 1 has some test code in the `tests` collection, 1 has an additional `example` collection, and 1 has an additional `attic` collection that doesn't have any .rkt files to avoid the code there ever being compiled. I think this suggests that single-collection is the right default. > If we go that way, then I'd characterize a single-collection package > without 'single-collection' in "info.rkt" as a low-quality package, but > a low-quality package is a fine starting point for a high-quality > package. Would this characterization be something reflected in any of the software, or just a recommendation we make to packagers? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] updated proposal for moving to packages
On Thu, Jun 6, 2013 at 9:23 AM, Matthew Flatt wrote: > Trying to characterize the milestones doesn't really seem to capture > the potential danger at this point, though. If we can build installers > that let users run DrRacket, then I think there's not so much that can > go wrong in terms of delivering a release. > > There are some potential problems; for example, I think DrRacket's rule > on when to compile packages in debugging mode needs a tweak. But that > level of danger is different from, say, the dangers of re-implementing > the snip, drawing, and GUI classes, where testing is more difficult. I think there are other things that can go wrong that are harder to test for: for example, the new system could fail to work with how some linux distribution builds Racket, or the way packages are laid out could conflict with some school's Windows file permission settings, or the new way that JS is used to fix links in documentation could not work on IE 6 (I hope we don't actually care if that happens). But I also don't think there's a way to find this out without trying. > At Wed, 5 Jun 2013 22:42:12 -0400, Sam Tobin-Hochstadt wrote: >> - I'm not entirely happy with the -doc/-lib/etc split, since it seems >> to make everything more verbose and difficult to work with. But I >> haven't tried developing in that environment, so maybe it's not a big >> deal. I also worry that it makes our repository less approachable to >> new people. > > I agree. One possibility is that few packages will be split so finely > --- only ones where the difference in dependencies is large and there > are clients for the low-dependency "-lib" package (in constrained > environments? in settings with frequent rebuilds?). If we don't > anticipate such clients, however, maybe we shouldn't try it at all. Right now, the core of the Typed Racket implementation [1] would be under two additional layers of directory structure, compared to the current tree. This would be annoying, but not deal-breaking. However, it occurs to me that splitting the `typed-racket` package into the `typed-racket-lib` and `typed-racket-doc` packages, with a `typed-racket` package that depended on them, would be a backward-compatible change for the future. Thus, I'd prefer to not split `typed-racket`, and maybe not anything except the core documentation, as a first cut. [1] https://github.com/mflatt/racket/blob/pkg/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/typecheck/tc-expr-unit.rkt > >> - We still don't have a ton of experience with the package system >> itself -- it's designated as beta in the current release, and there >> are very few packages with non-trivial dependencies. In contrast, the >> core repository has a lot of dependencies. For example, how will we >> deal with backwards-incompatible changes to the split itself, since >> packages are intended to be permanently compatible? > > Yes. This is both a significant difference and an example of a point > that's difficult to explore without the split. When we have a big core, > lots of packages can have zero dependencies other than the implicit > dependency on the core. With this in mind, I'll mention (without suggesting that we do it) another option: that we split into packages, but keep a much larger core than your `pkg` tree currently does -- all of the stack including DrRacket, for example. Then we'd gain experience, but not with portions that are quite as crucial. > When we have a small core, then there should be > practically no packages without explicit dependencies --- when a > package's dependencies are specified accurately, at least. Is it possible to enforce, either in the package system or in DrDr or somewhere else, that dependencies are specified accurately? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
At Thu, 6 Jun 2013 13:36:38 +0200, Laurent wrote: > > Some other the details: > > > > * A package's mode is recorded in the installed-package table. > >Otherwise, a linked package could switch modes just because the > >package directory's content changes, which would be difficult to > >keep in sync with the low-level table of links. > > > > Does it handle the case where user A installs B's single-collection > package, > and at some point B changes its package to a multi-collection package, > triggering the updating of A's installation? Yes. > What I'd like is to have single-collection being the default [...] > > So here is a demo patch attached to precise what I mean (without > test, would have taken me way too much time). Because it considers > that single-collections are the default, it is backward incompatible. > If info.rkt exists, it looks for 'multi-collection, and otherwise > looks for the 'collection-name string. I could go along with this, as long as (most?) everyone agrees, and as long as package authors are willing to update existing packages. If we go that way, then I'd characterize a single-collection package without 'single-collection' in "info.rkt" as a low-quality package, but a low-quality package is a fine starting point for a high-quality package. > If info.rkt does not exist, it creates it and gives the 'collection-name > the name of the package by default. That doesn't seem like a good idea to me. As you've noted, there can be problems with writing extra files. The collection name could be instead computed in `pkg-single-collection', which would treat the absence of an "info.rkt" to mean single-collection mode, right? Some calls to `pkg-single-collection' would need to change to pass in a package name to use instead of the `dir' name, since the `dir' argument is sometimes a temporary directory that is used to stage a package. That's an easy change. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] updated proposal for moving to packages
Okay. Good point about the relative difficulties of testing too. I am for 3. Robby On Thursday, June 6, 2013, Matthew Flatt wrote: > At Wed, 5 Jun 2013 21:26:51 -0500, Robby Findler wrote: > > For point 3., do you have a sense of what milestones we'd have to reach > (at > > what times) in order to have a successful release? > > The milestones I can see are > > * Get DrDr working with the new layout. > > * Automate snapshot and release builds (i.e., setting up client >machines and writing the coordinating layer on top of `make server' >and `make client'). > > Those seem like "next week" milestones to me. > > Trying to characterize the milestones doesn't really seem to capture > the potential danger at this point, though. If we can build installers > that let users run DrRacket, then I think there's not so much that can > go wrong in terms of delivering a release. > > There are some potential problems; for example, I think DrRacket's rule > on when to compile packages in debugging mode needs a tweak. But that > level of danger is different from, say, the dangers of re-implementing > the snip, drawing, and GUI classes, where testing is more difficult. > > The big things that can go wrong are longer term, like finding that the > package system doesn't do what we need and having to introduce a third > package system. The catch is that it seems difficult to know more about > what happens when we really adopt a way of working without really > adopting it. > > > At Wed, 5 Jun 2013 22:42:12 -0400, Sam Tobin-Hochstadt wrote: > > - I'm not entirely happy with the -doc/-lib/etc split, since it seems > > to make everything more verbose and difficult to work with. But I > > haven't tried developing in that environment, so maybe it's not a big > > deal. I also worry that it makes our repository less approachable to > > new people. > > I agree. One possibility is that few packages will be split so finely > --- only ones where the difference in dependencies is large and there > are clients for the low-dependency "-lib" package (in constrained > environments? in settings with frequent rebuilds?). If we don't > anticipate such clients, however, maybe we shouldn't try it at all. > > > - We still don't have a ton of experience with the package system > > itself -- it's designated as beta in the current release, and there > > are very few packages with non-trivial dependencies. In contrast, the > > core repository has a lot of dependencies. For example, how will we > > deal with backwards-incompatible changes to the split itself, since > > packages are intended to be permanently compatible? > > Yes. This is both a significant difference and an example of a point > that's difficult to explore without the split. When we have a big core, > lots of packages can have zero dependencies other than the implicit > dependency on the core. When we have a small core, then there should be > practically no packages without explicit dependencies --- when a > package's dependencies are specified accurately, at least. > > > At Wed, 05 Jun 2013 22:26:10 -0600, Neil Toronto wrote: > > Figuring out the details will go 20 times faster when we're all > > forced to work with them. I'm for #3. > > That's what I'm hoping. > > I think there are ways to gain more experience with the package system > without committing to it for the next release. For example, we could > have a parallel development track for a while. Those other options will > have overhead (maintaining two automatic-build systems would not be > fun, for example) and slow us down overall. I think we have time to > make a new way work, especially if the new way is all we're trying to > make work. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] updated proposal for moving to packages
At Wed, 5 Jun 2013 21:26:51 -0500, Robby Findler wrote: > For point 3., do you have a sense of what milestones we'd have to reach (at > what times) in order to have a successful release? The milestones I can see are * Get DrDr working with the new layout. * Automate snapshot and release builds (i.e., setting up client machines and writing the coordinating layer on top of `make server' and `make client'). Those seem like "next week" milestones to me. Trying to characterize the milestones doesn't really seem to capture the potential danger at this point, though. If we can build installers that let users run DrRacket, then I think there's not so much that can go wrong in terms of delivering a release. There are some potential problems; for example, I think DrRacket's rule on when to compile packages in debugging mode needs a tweak. But that level of danger is different from, say, the dangers of re-implementing the snip, drawing, and GUI classes, where testing is more difficult. The big things that can go wrong are longer term, like finding that the package system doesn't do what we need and having to introduce a third package system. The catch is that it seems difficult to know more about what happens when we really adopt a way of working without really adopting it. At Wed, 5 Jun 2013 22:42:12 -0400, Sam Tobin-Hochstadt wrote: > - I'm not entirely happy with the -doc/-lib/etc split, since it seems > to make everything more verbose and difficult to work with. But I > haven't tried developing in that environment, so maybe it's not a big > deal. I also worry that it makes our repository less approachable to > new people. I agree. One possibility is that few packages will be split so finely --- only ones where the difference in dependencies is large and there are clients for the low-dependency "-lib" package (in constrained environments? in settings with frequent rebuilds?). If we don't anticipate such clients, however, maybe we shouldn't try it at all. > - We still don't have a ton of experience with the package system > itself -- it's designated as beta in the current release, and there > are very few packages with non-trivial dependencies. In contrast, the > core repository has a lot of dependencies. For example, how will we > deal with backwards-incompatible changes to the split itself, since > packages are intended to be permanently compatible? Yes. This is both a significant difference and an example of a point that's difficult to explore without the split. When we have a big core, lots of packages can have zero dependencies other than the implicit dependency on the core. When we have a small core, then there should be practically no packages without explicit dependencies --- when a package's dependencies are specified accurately, at least. At Wed, 05 Jun 2013 22:26:10 -0600, Neil Toronto wrote: > Figuring out the details will go 20 times faster when we're all > forced to work with them. I'm for #3. That's what I'm hoping. I think there are ways to gain more experience with the package system without committing to it for the next release. For example, we could have a parallel development track for a while. Those other options will have overhead (maintaining two automatic-build systems would not be fun, for example) and slow us down overall. I think we have time to make a new way work, especially if the new way is all we're trying to make work. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Great! Thank you very much. On Wed, Jun 5, 2013 at 11:04 PM, Matthew Flatt wrote: > More generally, I hope I haven't come across as being firmly opposed to > the idea of single-collection packages. I intended to come across as > being opposed to implementing the idea myself. :) > I wanted to give it a stab, but didn't have much time. Plus you did it way better than I could have done anyway. > Some other the details: > > * A package's mode is recorded in the installed-package table. >Otherwise, a linked package could switch modes just because the >package directory's content changes, which would be difficult to >keep in sync with the low-level table of links. > Does it handle the case where user A installs B's single-collection package, and at some point B changes its package to a multi-collection package, triggering the updating of A's installation? As Jay pointed out to me, putting the collection name in the "info.rkt" > file --- instead of using the package name as the collection name --- > makes the package content work the same even when the package is > renamed. Otherwise, you have to know whether the package is > single-collection or multi-collection to know whether changing the > package's name changes its content. > > It's debatable whether single-collection or multi-collection would be a > better default, but I favor multi-collection mode. > What I'd like is to have single-collection being the default so that the average Joe can even not care about including a info.rkt file, and expect the collection's name to be just the directory's name. Less burden on the user -> more packages. I believe most users will not even (try to) understand the concept of multi- collection packages. To them a package is just a bunch of source files and that's all. Then to create a simple package, Joe only has to create a directory, put his my-file.rkt in it, and he's done! If at some point Joe thinks about having a different name for his package and for his collection, it should be intuitive to him that he should say so somewhere (i.e. in the info.rkt file). So here is a demo patch attached to precise what I mean (without test, would have taken me way too much time). Because it considers that single-collections are the default, it is backward incompatible. If info.rkt exists, it looks for 'multi-collection, and otherwise looks for the 'collection-name string. If info.rkt does not exist, it creates it and gives the 'collection-name the name of the package by default. (This of course fails if the directory is read-only, but since it's just a useful default it should not be a problem. This should at least work for all downloaded archives.) Laurent lib.rkt.patch Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
