[racket-dev] Typed versions of untyped collections

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Dec 17 15:49:44 EST 2012

I think TR does have some of this facility already.

Robby


On Mon, Dec 17, 2012 at 2:41 PM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:

>
> When Neil created his library, I proposed that he create one piece of
> source code and 'generate' both the typed and untyped module from it.
>
> If we foresee this kind of library to become more common, we should
> probably provide the capability as an abstraction from TR.
>
> -- Matthias
>
>
>
>
>
> On Dec 17, 2012, at 3:27 PM, Robby Findler 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 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.
> >
> > If the convention how the names get adjusted and whatnot is just
> documented, then every library writer can provide both versions.
> >
> > And yes, there are details I'm glossing over here, but just doing
> nothing isn't helping.
> >
> > Robby
> >
> > _________________________
> >  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/99ca53a3/attachment-0001.html>

Posted on the dev mailing list.