On Jun 2, 2015, at 1:20 AM, Matthew Butterick <[email protected]> wrote:
> I've increasingly been using TR this way (= keeping code in a state where it > can be easily toggled between typechecked and not). It works, though I'm > still thinking about how to achieve better ergonomics with these issues, > which don't have automatic solutions: > > Q1. How to toggle between `#lang typed/...` and `#lang typed/.../no-check` in > a group of files. It is becoming clear to me that we need to integrate some of the file system into our module-level scope. At that point, we could expand refactoring (like alpha-renaming or this kind of type toggling) to these things. > Q2. How to `(require ...)` typed or untyped versions of other libraries > depending on whether I'm running in `no-check` mode. The NU group is working on a performance evaluation experiment that needs just this kind of syntactic abstraction. We should probably work it into something useful. > Q3. How to preserve the semantics of type-derived predicates in `no-check`, > which otherwise all become false. Well, that's the $10M question. At what price soundness? -- Matthias > > (define-predicate foo? FooType) > (foo? x) ;; in `no-check` this will always return #f, which breaks the code > > > > > > On Jun 1, 2015, at 4:39 PM, Sam Tobin-Hochstadt <[email protected]> wrote: > >> Yes, if you just change `#lang typed/racket/base` to `#lang >> typed/racket/base/no-check`, that's what you'll get. >> >> Sam >> >> On Mon, Jun 1, 2015 at 10:34 PM, John Carmack <[email protected]> wrote: >>> Is there an option to parse all the type annotations, but not do any of the >>> checking? Highly interactive tuning sessions could work without type >>> checking, then turn it back on for structural work. >>> >>> >>> >>>> On Jun 1, 2015, at 9:05 PM, Sam Tobin-Hochstadt <[email protected]> >>>> wrote: >>>> >>>> Unfortunately, Typed Racket typechecking is pretty slow, and so the >>>> times you have there are not out of the ordinary. The most significant >>>> thing that's slow in Typed Racket is type checking numeric operations, >>>> because both the numbers themselves and the operations have >>>> complicated types. >>>> >>>> If you can say more about the program in particular, I can maybe >>>> suggest something that would speed it up, but it's currently a >>>> combination of expensive-in-principle algorithms and not being >>>> designed for speed many years ago when I started. >>>> >>>> Sam >>>> >>>>> On Mon, Jun 1, 2015 at 9:06 PM, John Carmack <[email protected]> wrote: >>>>> I am working on a little project to remotely drive a VR headset with code >>>>> written in Racket as an attempt to make a significantly faster development >>>>> environment for certain types of VR apps. I am worried about what appears >>>>> to be the compile speed. >>>>> >>>>> >>>>> >>>>> It takes over three seconds from hitting ctrl-R in DrRacket to executing >>>>> the >>>>> first statement of a 350 line typed racket program. It only uses: >>>>> >>>>> #lang typed/racket/base >>>>> >>>>> (require racket/tcp) >>>>> >>>>> >>>>> >>>>> That seems to be about twice as slow as a larger untyped racket program >>>>> using a bunch more stuff, but even that isn’t great: >>>>> >>>>> #lang racket >>>>> >>>>> (require 2htdp/universe) >>>>> >>>>> (require 2htdp/image) >>>>> >>>>> (require 2htdp/planetcute) >>>>> >>>>> (require (only-in racket/gui/base play-sound)) >>>>> >>>>> >>>>> >>>>> Does Run from DrRacket have a significant time penalty? >>>>> >>>>> Are there any steps I can take to make typed racket compile faster? >>>>> >>>>> In many cases I don’t care much about the execution speed. >>>>> >>>>> >>>>> >>>>> I would like to think that compiling and running a few hundred lines of >>>>> code >>>>> on a modern desktop system should be essentially instant. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Racket Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Racket Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
