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