Nice summary.<div><br></div><div>Yes, in my experience so far, there is higher than anticipated pain when attempting to re-use pre-existing libraries written in R by lifting them to TR. <div><br></div><div>When writing green-field code in TR mostly things are a joy (more aggressive inferencing would be a nice improvement). One tends to work with TR accepting what it offers and steering clear of the usual standard static typing constraint pot-holes. When writing R code one tends to adopt the Lisp'ish way, which can be at odds with the ML'ish way.<div> <br></div><div>In my experience lifting R -> TR is harder than TR -> R. Yet getting people to write TR first with a transform to R will be a huge shift for the community, maybe a non-starter. Forking core collections libraries into two code bases doesn't make sense.</div> <div><br></div><div>If the path is to baseline the current collections/... in R and also write new collection libraries in R with a finishing polish of a R -> TR wrapping I'm not sure it will work out smoothly. Ultimately I expect a non-insignificant amount of R code in collects/... would best be re-written with a TR lifting in mind. And the development of new collections done with TR in mind a priori, dual written in tandem or written in TR initially with a TR -> R finishing step.</div> <div><br></div><div>I'm biased but personally I think collects/... should be rewritten in toto to TR with a standard TR -> R `require' option or transformation on setup/install. Huge effort there to say the least. Wrapping existing R code in TR 'in situ' will probably not work. That doesn't mean it can't be done, but there will always be an impedance mismatch at the performance level and an accompanying awkwardness at the API level.</div> </div></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 6, 2012 at 9:56 AM, Dan Burton <span dir="ltr"><<a href="mailto:danburton.email@gmail.com" target="_blank">danburton.email@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good idea; I've modified the post title as you recommended.<div><span class="HOEnZb"><font color="#888888"><br clear="all"> -- Dan Burton</font></span><div><div class="h5"><br> <br><br><div class="gmail_quote">On Tue, Nov 6, 2012 at 7:34 AM, Matthias Felleisen <span dir="ltr"><<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Thanks for the feedback.<br> <br> You labeled the blog "my experience with typed racket" but you focus<br> on the negative points. Perhaps you want to add ", the Negative Parts"<br> to the title because your introduction makes it clear that you find<br> a few good things.<br> <br> -- Matthias<br> <div><div><br> <br> <br> On Nov 5, 2012, at 5:46 PM, Dan Burton wrote:<br> <br> > I've published a blog post about Typed Racket that I've been holding on to for a while.<br> > Mainly I intended it as feedback for Sam about what areas of TR I think can be improved,<br> > though it does provide a sort of tour through lots of Typed Racket features,<br> > so it should be readable by anyone with familiarity with Racket.<br> ><br> > <a href="http://unknownparallel.wordpress.com/2012/11/05/my-experience-with-typed-racket/" target="_blank">http://unknownparallel.wordpress.com/2012/11/05/my-experience-with-typed-racket/</a><br> ><br> > If I've made any errors, please let me know and I will correct them posthaste.<br> ><br> > -- Dan Burton<br> </div></div>> _________________________<br> > Racket Developers list:<br> > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> <br> </blockquote></div><br></div></div></div> <br>_________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> <br></blockquote></div><br></div>