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. <div><br></div><div>
<a href="https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-env.rkt">https://github.com/plt/racket/blob/master/collects/typed-racket/base-env/base-env.rkt</a><br></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Mon, Dec 17, 2012 at 1:16 PM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>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.<br>
<br>And while I do understand Sam's reluctance to mess with module resolution, I think that just not solving this problem is worse.<br><br>And finally (and perhaps this is the root of the problem), I cannot understand what TR actually does by reading its documentation.<br>
<br>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.<div>
<span class="HOEnZb"><font color="#888888">
<br>Robby</font></span><div><div class="h5"><br><br>On Mon, Dec 17, 2012 at 2:51 PM, Sam Tobin-Hochstadt <<a href="mailto:samth@ccs.neu.edu" target="_blank">samth@ccs.neu.edu</a>> wrote:<br>><br>> On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler<br>
> <<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>> wrote:<br>
> > I've long thought something along these lines is a good idea, but perhaps<br>> > what I think is a good idea isn't what Matthias and Sam think is the bad<br>> > idea.<br>> ><br>> > I think that it makes sense for 'require' in typed-racket to look in a<br>
> > different place than 'require' in untyped racket looks so that one can write<br>> > the same require spec (in both the docs and the code) and have two versions<br>> > of the same library, one that is typed and one that isn't typed. Then, then<br>
> > library writer, if they choose, can decide who pays what for going (or not)<br>> > across the boundary between typed and untyped. (Or maybe submodules would be<br>> > better.)<br>><br>> I think this is exactly what Eli was suggesting, and what I think is a bad idea.<br>
><br>> > I think this is already happening in TR anyways, when I write<br>> ><br>> > (require racket/list)<br>> ><br>> > I don't get the same file being loaded when that is in a TR program as when<br>
> > it is in a R program.<br>><br>> You get *exactly* the same file as in R. I think that (a) this is a<br>> valuable invariant and (b) the mechanisms for violating this invariant<br>> are all very worrying.<br>
><br>> Sam</div></div></div>
<br>_________________________<br>
Racket Developers list:<br>
<a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
<br></blockquote></div><br></div>