<div dir="ltr"><br><div class="gmail_extra">On Thu, May 23, 2013 at 9:39 AM, Matthias Felleisen <span dir="ltr">&lt;<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>&gt;</span> wrote:<br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On May 23, 2013, at 9:34 AM, Sam Tobin-Hochstadt &lt;<a href="mailto:samth@ccs.neu.edu">samth@ccs.neu.edu</a>&gt; wrote:<br>
<br>
&gt;&gt; 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?<br>
&gt;<br>
&gt; No. We can&#39;t specify types inside `racket/base` without making `racket/base` depend on Typed Racket.<br>
<br>
<br>
</div>1. I was proposing a fundamental change to the language, with an eye toward Racket 2.<br>
<br>
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.<br>

</blockquote><div><br></div><div>It shouldn&#39;t be necessary to specify types inside racket/base; it&#39;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-&lt;foo&gt; or exporting them from a submodule named &quot;private&quot; -- 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.<br>

</div><br></div>--Carl<br></div></div>