[racket-dev] Typed versions of untyped collections

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
<robby at 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.dobson at 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
>> <robby at 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 <samth at ccs.neu.edu>
>>> wrote:
>>> >
>>> > On Mon, Dec 17, 2012 at 3:27 PM, Robby Findler
>>> > <robby at 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
>>>
>>
>