[racket-dev] Typed versions of untyped collections

Fine. I give up.

Robby


On Mon, Dec 17, 2012 at 7:55 PM, Sam Tobin-Hochstadt <samth at 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
> <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
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121217/53c3f34e/attachment.html>