This sounds like the right solution to me too. Robby
On Thursday, May 23, 2013, Matthias Felleisen wrote: > > +1 > > > On May 23, 2013, at 9:42 AM, Carl Eastlund <c...@ccs.neu.edu <javascript:;>> > wrote: > > > > > On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen < > matth...@ccs.neu.edu <javascript:;>> wrote: > > > > On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt > > <sa...@ccs.neu.edu<javascript:;>> > wrote: > > > > >> 2. Is it possible that we could solve the problem via a > bootstrapping-only violation of our policy that you can add types to Racket > w/o modifying existing modules? > > > > > > No. We can't specify types inside `racket/base` without making > `racket/base` depend on Typed Racket. > > > > > > 1. I was proposing a fundamental change to the language, with an eye > toward Racket 2. > > > > 2. I was also proposing an experiment that temporarily creates such a > dependency and we can then look for a refactoring that breaks the > dependency again but in a way that supports the proper access to these base > identifiers. > > > > It shouldn't be necessary to specify types inside racket/base; it's only > necessary to make the identifiers available somehow. Then TR can do the > type specification, but without using namespaces. Protecting the exported > identifiers from misuse could be done by convention -- naming them > unsafe-<foo> or exporting them from a submodule named "private" -- or by > enforcement -- for instance, rather than providing them, instead exporting > a phase 1 syntax object that contains them with appropriate syntax taints / > dye packs so that they can be used for free-identifier=? but not put into > expanded code. > > > > --Carl > > > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
