Fine. I give up. Robby
On Mon, Dec 17, 2012 at 7:55 PM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu>wrote: > I, perhaps unsurprisingly, disagree. If `listt.rkt` re-provided > everything from `list.rkt`, then it would continue to work. These > decisions are made entirely on the basis of the particular identifiers > involved -- which module is loaded has nothing to do with it. > > But regardless of exactly how types are declared for the builtin > modules (this could be done with submodules instead, potentially, in > which case the copying would work), right now TR does not translate > requires at all, and I'd like to keep it that way > > On Mon, Dec 17, 2012 at 4:30 PM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: > > For the purposes of this conversation, I don't think it is fair to stop > > after the comma in your sentence, Eric. :) > > > > Robby > > > > > > On Mon, Dec 17, 2012 at 3:29 PM, Eric Dobson <eric.n.dob...@gmail.com> > > wrote: > >> > >> It is getting exactly the same file as R, except there is a special file > >> in the TR code that gives types to some bindings (all of the ones from > >> racket). Your new module's bindings are not in this file. > >> > >> > >> > https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-env.rkt > >> > >> > >> On Mon, Dec 17, 2012 at 1:16 PM, Robby Findler > >> <ro...@eecs.northwestern.edu> wrote: > >>> > >>> I don't understand Matthias's performance comments. If, in TR (require > >>> plot) actually gives me a typed version of the library and in R > (require > >>> plot) gives me the untyped version of the library, then I am avoiding > the > >>> performance the untyped/typed performance overhead properly. If, on the > >>> other hand, if I have to commit that (require plot) gives me either the > >>> untyped or the typed version, then I have to suffer the performance > overhead > >>> when I require it from the "wrong" context. > >>> > >>> Neil's original complaint also has validity, I think: if he provides a > >>> plot/typed today, and then later ports plot so it is typed, then he > has to > >>> keep this extra thing around for what appears to not be a very good > reason. > >>> > >>> And while I do understand Sam's reluctance to mess with module > >>> resolution, I think that just not solving this problem is worse. > >>> > >>> And finally (and perhaps this is the root of the problem), I cannot > >>> understand what TR actually does by reading its documentation. > >>> > >>> For example, the docs for 'require' do not explain why I can make a > copy > >>> of "list.rkt" (in the racket collection), call the copy "listt.rkt" > and have > >>> that copy not work, but the original one does. Clearly TR is not just > >>> "get[ting] *exactly* the same file as in R", so I think Sam's comments > are > >>> off base. > >>> > >>> Robby > >>> > >>> > >>> On Mon, Dec 17, 2012 at 2:51 PM, Sam Tobin-Hochstadt < > sa...@ccs.neu.edu> > >>> wrote: > >>> > > >>> > On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler > >>> > <ro...@eecs.northwestern.edu> wrote: > >>> > > I've long thought something along these lines is a good idea, but > >>> > > perhaps > >>> > > what I think is a good idea isn't what Matthias and Sam think is > the > >>> > > bad > >>> > > idea. > >>> > > > >>> > > I think that it makes sense for 'require' in typed-racket to look > in > >>> > > a > >>> > > different place than 'require' in untyped racket looks so that one > >>> > > can write > >>> > > the same require spec (in both the docs and the code) and have two > >>> > > versions > >>> > > of the same library, one that is typed and one that isn't typed. > >>> > > Then, then > >>> > > library writer, if they choose, can decide who pays what for going > >>> > > (or not) > >>> > > across the boundary between typed and untyped. (Or maybe submodules > >>> > > would be > >>> > > better.) > >>> > > >>> > I think this is exactly what Eli was suggesting, and what I think is > a > >>> > bad idea. > >>> > > >>> > > I think this is already happening in TR anyways, when I write > >>> > > > >>> > > (require racket/list) > >>> > > > >>> > > I don't get the same file being loaded when that is in a TR program > >>> > > as when > >>> > > it is in a R program. > >>> > > >>> > You get *exactly* the same file as in R. I think that (a) this is a > >>> > valuable invariant and (b) the mechanisms for violating this > invariant > >>> > are all very worrying. > >>> > > >>> > Sam > >>> > >>> _________________________ > >>> Racket Developers list: > >>> http://lists.racket-lang.org/dev > >>> > >> > > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
