Re: [racket-dev] [plt] Push #26939: master branch updated
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 type, but doesn't work so well in other cases.
For example in a reduced version of the test case:
#lang typed/racket
;; Test for PR 13821
;;
;; Make sure type instantiation with struct names doesn't
;; loop forever
(struct: (X) union ([fst : (ISet X)]) #:transparent)
(struct: (X) complement ([fst : (ISet X)]) #:transparent)
(define-type (ISet X) (U (union X) (complement X) (Setof X)))
;; This involves type instantiation and could loop forever
;; with the bug
(: iset->set (All (X) ((ISet X) -> (Setof X
(define (iset->set A)
(union? A)
(error 'unimplemented))
;; A simpler way to reproduce the problem
(union? 5)
I get the output from my logging:
> > > > (resolve-once (union Any))
> > > > >(Un (Setof Any) (union Any) (complement Any))
Union of ((Setof Any) (union Any) (complement Any))
Merging (Setof Any) and ()
> > > > > (subtype (Setof Any) (U))
Current seen 27457 1 ((27222 . 27457) (27261 . 27457) (27317 . 27222))
< < < < < #f
> > > > > (subtype (U) (Setof Any))
Current seen 1 27457 ((27222 . 27457) (27261 . 27457) (27317 . 27222))
< < < < < #t
Merging (complement Any) and ((Setof Any))
> > > > > (subtype (complement Any) (Setof Any))
Current seen 27261 27457 ((27222 . 27457) (27261 . 27457) (27317 . 27222))
< < < < < #t
Merging (union Any) and ((Setof Any))
> > > > > (subtype (union Any) (Setof Any))
Current seen 27222 27457 ((27222 . 27457) (27261 . 27457) (27317 . 27222))
< < < < < #t
< < < < <(Setof Any)
< < < <
#(struct:# ((Setof Any)))
Which shows that (union Any) is resolving incorrectly to (struct union
((Setof Any))) instead of (struct union ((U (union Any) (complement
Any) (Setof Any.
All your change does is prevent one call site of resolve, and thus
just covers up the issue instead of solving it.
On Fri, Jun 7, 2013 at 12:14 PM, wrote:
> asumu has updated `master' from 3d6776680c to 75f0c88feb.
> http://git.racket-lang.org/plt/3d6776680c..75f0c88feb
>
> =[ 3 Commits ]==
> Directory summary:
>8.7% collects/tests/typed-racket/fail/
> 25.5% collects/tests/typed-racket/succeed/
> 15.3% collects/tests/unstable/
> 24.3% collects/typed-racket/types/
> 13.9% collects/unstable/scribblings/
> 12.0% collects/unstable/
>
> ~~
>
> 12e5bc6 Asumu Takikawa 2013-06-07 14:31
> :
> | Add match*? to unstable/match
> :
> M collects/tests/unstable/match.rkt | 15 ++-
> M collects/unstable/match.rkt | 10 +-
> M collects/unstable/scribblings/match.scrbl | 19 +++
>
> ~~
>
> c8e281a Asumu Takikawa 2013-06-07 14:32
> :
> | Fix union merging
> |
> | Trying to merge (and thus resolve) applications of struct
> | types would cause infinite looping on type instantiation
> | if the struct type used both a union and recursion.
> |
> | Closes PR 13821
> :
> A collects/tests/typed-racket/succeed/pr13821.rkt
> M collects/typed-racket/types/union.rkt | 14 --
>
> ~~
>
> 75f0c88 Asumu Takikawa 2013-06-07 15:08
> :
> | Improve TR test case
> :
> M collects/tests/typed-racket/fail/pr13209.rkt | 7 ++-
>
> =[ Overall Diff ]===
>
> collects/tests/typed-racket/fail/pr13209.rkt
>
> --- OLD/collects/tests/typed-racket/fail/pr13209.rkt
> +++ NEW/collects/tests/typed-racket/fail/pr13209.rkt
> @@ -1,7 +1,12 @@
> #;
> -(exn-pred exn:fail:syntax?)
> +(exn-pred #rx"arguments for structure type constructor")
> #lang typed/racket
>
> +;; Test for PR 13209
> +;;
> +;; The use of `node` at the end has the wrong number of
> +;; type arguments. This should not raise an internal error.
> +
> (struct: (α) leaf ({value : α}))
> (struct: (α) node ({left : [Tree α]} {right : [Tree α]}))
>
>
> collects/tests/typed-racket/succeed/pr13821.rkt
> ~~~
> --- /dev/null
> +++ NEW/collects/tests/typed-racket/succeed/pr13821.rkt
> @@ -0,0 +1,22 @@
> +#lang typed/racket
> +
> +;; Test for PR 13821
> +;;
> +;; Make sure type instantiation with struct names doesn't
> +;; loop forever
> +
> +(struct: (X) union ([fst : (ISet X)] [snd : (ISet X)]) #:transparent)
> +(struct: (X) intersection ([fst : (ISet X)] [snd : (ISet X)]) #:transparent)
> +(struct: (X) complement ([fst : (ISet X)] [snd : (ISet X)]) #:transparent)
> +(define-type (ISet X) (U (union X) (intersection X) (complement X) (Setof
> X)))
> +
> +;; This involves type instantiation and could loop forever
> +;; with the bug
> +(: iset->set (All (X) ((ISet X) -> (Setof X
> +(define (iset->set A)
> + (union? A)
> + (error 'unimplemented))
> +
> +;; A simpler way to reprodu
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
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 -- as "top-level" A and B collections. (Although you make A and B into subdirs of a package dir when preparing a multi-collection package -- even though you "push them down" for that prep -- when installed they'll be "hoisted back up" side by side with other collections.) On Fri, Jun 7, 2013 at 5:04 PM, Jay McCarthy wrote: > On Fri, Jun 7, 2013 at 2:49 PM, Greg Hendershott > 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 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. >> >> Likewise I'd be happy to update all of mine. >> >> >> As I thought about this, I realized I have what feels like a _really_ >> dumb question. I realize maybe I don't have a crisp handle on >> "collection", "library", "module", and "subdirectory". > > (require a/b/c x/y/z) > > A collection is something that comes first in a require: a and x. > A library normally means module, but might be a general term for "code I > share". > A module path is the full path: a/b/c and x/y/z. > A module is a file: "a/b/c.rkt" and "x/y/z.rkt" > A module has a 'short name': 'c and 'z (but you normally don't think about > it.) > A subdirectory is where a file might be and shows up in the module path. > A package is a set of modules. > > Some documentation might refer to subdirectories as "sub collections". > > This whole debate has been about whether a SINGLE package can have > MANY modules from DIFFERENT collections. > > Can package "P" have module a/b/c AND x/y/z? > Does package "P" have to have a collection "P"? > > The current package system puts no restriction on what modules a > package can have in it. > > The proposed patch supported vigorously by Sam is to restrict some > packages so that the can only have modules from one collection. Since > this restriction is only on some packages, it doesn't take power from > the system. And some people believe that this restriction is more > convenient, because they do not have to come up with a name for P or a > directory for it. There is a second debate on the point of whether the > collection name of a restricted package P must be P. > > Jay > >> A single collection can have multiple modules, correct? At what point >> does it become "multiple collections" -- simply because some of the >> modules are in subdirs? >> >> In other words: >> >> my-collection/ >> subidr1/ >> subdir2/ >> >> Is that 1 collection or 3? And why? >> >> Is the answer related to whether there's an info.rkt in a subdir? >> >> The discussion at http://docs.racket-lang.org/guide/module-basics.html >> doesn't clear this up for me (unless I'm overlooking something on >> multiple re-reads). 6.1.1. has an example of modules organized in >> subdirs. This feels like "one collection" but the term hasn't been >> introduced yet. 6.1.2 starts talking about library collections, and >> says "A collection is a set of installed library modules". But it >> doesn't say "modules only in the same directory", and it doesn't >> really explain at what point it would be considered separate sets of >> modules, i.e. two collections instead of one. >> >> Again, I feel like I'm being dense and will probably be embarrassed >> when I hear the answer, but ... there. I asked. >> _ >> 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
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Fri, Jun 7, 2013 at 2:49 PM, Greg Hendershott 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 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. > > Likewise I'd be happy to update all of mine. > > > As I thought about this, I realized I have what feels like a _really_ > dumb question. I realize maybe I don't have a crisp handle on > "collection", "library", "module", and "subdirectory". (require a/b/c x/y/z) A collection is something that comes first in a require: a and x. A library normally means module, but might be a general term for "code I share". A module path is the full path: a/b/c and x/y/z. A module is a file: "a/b/c.rkt" and "x/y/z.rkt" A module has a 'short name': 'c and 'z (but you normally don't think about it.) A subdirectory is where a file might be and shows up in the module path. A package is a set of modules. Some documentation might refer to subdirectories as "sub collections". This whole debate has been about whether a SINGLE package can have MANY modules from DIFFERENT collections. Can package "P" have module a/b/c AND x/y/z? Does package "P" have to have a collection "P"? The current package system puts no restriction on what modules a package can have in it. The proposed patch supported vigorously by Sam is to restrict some packages so that the can only have modules from one collection. Since this restriction is only on some packages, it doesn't take power from the system. And some people believe that this restriction is more convenient, because they do not have to come up with a name for P or a directory for it. There is a second debate on the point of whether the collection name of a restricted package P must be P. Jay > A single collection can have multiple modules, correct? At what point > does it become "multiple collections" -- simply because some of the > modules are in subdirs? > > In other words: > > my-collection/ > subidr1/ > subdir2/ > > Is that 1 collection or 3? And why? > > Is the answer related to whether there's an info.rkt in a subdir? > > The discussion at http://docs.racket-lang.org/guide/module-basics.html > doesn't clear this up for me (unless I'm overlooking something on > multiple re-reads). 6.1.1. has an example of modules organized in > subdirs. This feels like "one collection" but the term hasn't been > introduced yet. 6.1.2 starts talking about library collections, and > says "A collection is a set of installed library modules". But it > doesn't say "modules only in the same directory", and it doesn't > really explain at what point it would be considered separate sets of > modules, i.e. two collections instead of one. > > Again, I feel like I'm being dense and will probably be embarrassed > when I hear the answer, but ... there. I asked. > _ > 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
Re: [racket-dev] PLaneT(2): Single vs multi-collection 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. Likewise I'd be happy to update all of mine. As I thought about this, I realized I have what feels like a _really_ dumb question. I realize maybe I don't have a crisp handle on "collection", "library", "module", and "subdirectory". A single collection can have multiple modules, correct? At what point does it become "multiple collections" -- simply because some of the modules are in subdirs? In other words: my-collection/ subidr1/ subdir2/ Is that 1 collection or 3? And why? Is the answer related to whether there's an info.rkt in a subdir? The discussion at http://docs.racket-lang.org/guide/module-basics.html doesn't clear this up for me (unless I'm overlooking something on multiple re-reads). 6.1.1. has an example of modules organized in subdirs. This feels like "one collection" but the term hasn't been introduced yet. 6.1.2 starts talking about library collections, and says "A collection is a set of installed library modules". But it doesn't say "modules only in the same directory", and it doesn't really explain at what point it would be considered separate sets of modules, i.e. two collections instead of one. Again, I feel like I'm being dense and will probably be embarrassed when I hear the answer, but ... there. I asked. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] updated proposal for moving to packages
At Thu, 6 Jun 2013 11:35:20 -0600, Jay McCarthy wrote: > On Thu, Jun 6, 2013 at 9:33 AM, Matthew Flatt 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 `require's). Approximate checks would be useful, and I > > don't think anyone has implemented them, yet. [...] > > 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? Yes. Specifically, I think `raco setup' could * check imports in ".zo" files (skipping "_scrbl.zo" files) to make sure that they are included in the enclosing package's `deps', and * check dependencies recorded in ".dep" files (including "_scrbl.dep") to make sure that they are included in the enclosing package's `deps' plus `build-deps'. _ Racket Developers list: http://lists.racket-lang.org/dev
