I implemented what I thought would do this a long time ago, so if it isn't there then I must be misremembering or things have changed in the code to make it not happen.
Sam On Sep 9, 2013 9:13 PM, "Eric Dobson" <eric.n.dob...@gmail.com> wrote: > When did you add this? Last time I checked (June-ish) this was not > added. Can you point to the code that does it? > > On Mon, Sep 9, 2013 at 5:55 PM, Sam Tobin-Hochstadt > <sa...@cs.indiana.edu> wrote: > > Not only did our own Sam write about this, but he thought that he changed > > Typed Racket to do this. Am I missing something here, or are you > describing > > more optimization than we do already or ...? > > > > Sam > > > > On Sep 9, 2013 8:33 PM, "Robby Findler" <ro...@eecs.northwestern.edu> > wrote: > >> > >> FWIW, this is something that's been studied in small calculi in the > >> literature. Nothing that will have to get thru all of the little details > >> that you have to get right to make it work in a real language design > like > >> TR, but maybe you'll find some useful ways to look at the problem. > (Mostly > >> the papers I'm thinking of have Jeremy Siek as a co-author but there are > >> others, including our own Sam.) > >> > >> Robby > >> > >> > >> On Mon, Sep 9, 2013 at 7:14 PM, Eric Dobson <eric.n.dob...@gmail.com> > >> wrote: > >>> > >>> I have ideas to remove about the contracts from TR code, but currently > >>> that is only prototyped. > >>> > >>> Example: > >>> > >>> #lang typed/racket > >>> (provide f) > >>> (: f (Number -> Number)) > >>> (define (f x) x) > >>> > >>> Currently f is exported with the contract (number? . -> . number?), > >>> but this can be safely reduced to (number . -> . any). This is because > >>> the return value contract is checking things we have already ensured > >>> statically. IIRC checking return values of functions is much more > >>> expensive than just arguments, so this should reduce the cost of TR > >>> boundary cost, but I don't have any numbers. > >>> > >>> On Mon, Sep 9, 2013 at 10:57 AM, Sam Tobin-Hochstadt > >>> <sa...@cs.indiana.edu> wrote: > >>> > On Mon, Sep 9, 2013 at 11:35 AM, Neil Toronto < > neil.toro...@gmail.com> > >>> > wrote: > >>> >> Nice, and thanks for the explanation. Just to make sure I get it: > does > >>> >> this > >>> >> mean fully expanded TR modules are smaller? > >>> > > >>> > Yes. > >>> > > >>> >> Does it reduce the number of generated contracts? > >>> > > >>> > No. > >>> > > >>> >> > >>> >> > >>> >> On 09/08/2013 12:24 PM, Sam Tobin-Hochstadt wrote: > >>> >>> > >>> >>> Typed Racket has to expand into code that registers the type of > each > >>> >>> module-top-level identifier in the global environment so that other > >>> >>> modules can find the types to typecheck with. For example, this > >>> >>> program: > >>> >>> > >>> >>> #lang typed/racket > >>> >>> (provide x) > >>> >>> (define: x : Integer 1) > >>> >>> > >>> >>> expands into (greatly simplified): > >>> >>> > >>> >>> #lang ... > >>> >>> (#%provide x) > >>> >>> (begin-for-syntax > >>> >>> (declare #'x Integer-rep)) > >>> >>> (define-values (x) 1) > >>> >>> > >>> >>> but what is `Integer-rep`? It needs to be an expression that > >>> >>> _constructs_ the internal Typed Racket representation of the > >>> >>> `Integer` > >>> >>> type. Previously, that looked something like this: > >>> >>> > >>> >>> (make-Union (sort (list Negative-Fixnum-rep > Positive-Fixnum-rep > >>> >>> ...))) > >>> >>> > >>> >>> and so on and so forth for the components, all the way down to base > >>> >>> types. You can imagine how this gets quite large, especially for > >>> >>> large types. > >>> >>> > >>> >>> However, this is wasteful, because every Typed Racket program, at > >>> >>> type > >>> >>> checking time, defines a constant that's the representation of the > >>> >>> `Integer` type, right here [1]. So instead of serializing an > >>> >>> expression that constructs the same thing as `-Int`, we can just > >>> >>> *reference* `-Int` in the expanded code. To make that possible, > >>> >>> Typed > >>> >>> Racket now builds a hash table [2] mapping types (really, their > >>> >>> representations) to identifiers that denote those types. Then the > >>> >>> serializer just consults this table [3]. > >>> >>> > >>> >>> It turns out that base types (but no others) already used basically > >>> >>> this mechanism, by storing the identifier *in* the type > >>> >>> representation. But that's now obsolete, and thus was removed in > my > >>> >>> subsequent commit. > >>> >>> > >>> >>> As a result, the type serialization is much smaller. > >>> >>> > >>> >>> [1] > >>> >>> > >>> >>> > https://github.com/plt/racket/blob/master/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/types/numeric-tower.rkt#L107 > >>> >>> [2] > >>> >>> > >>> >>> > https://github.com/plt/racket/blob/master/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/types/base-abbrev.rkt#L23 > >>> >>> [3] > >>> >>> > >>> >>> > https://github.com/plt/racket/blob/master/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/env/init-envs.rkt#L51 > >>> >>> > >>> >>> On Sat, Sep 7, 2013 at 3:20 PM, Neil Toronto < > neil.toro...@gmail.com> > >>> >>> wrote: > >>> >>>> > >>> >>>> On 09/06/2013 04:14 PM, sa...@racket-lang.org wrote: > >>> >>>>> > >>> >>>>> > >>> >>>>> 56b372c Sam Tobin-Hochstadt <sa...@racket-lang.org> 2013-09-06 > >>> >>>>> 14:22 > >>> >>>>> : > >>> >>>>> | Remember types that are defined, and use them in serialization. > >>> >>>>> | > >>> >>>>> | This extends a facility already available for base types, > >>> >>>>> | making that facility no longer strictly needed. > >>> >>>>> | > >>> >>>>> | Shrinks the zo size for the `math` package by almost 1MB. > >>> >>>>> : > >>> >>>>> M .../typed-racket/env/init-envs.rkt | 1 + > >>> >>>>> M .../typed-racket/typecheck/def-export.rkt | 7 +- > >>> >>>>> M .../typed-racket/typecheck/tc-toplevel.rkt | 31 > >>> >>>>> +++--- > >>> >>>>> M .../typed-racket/types/abbrev.rkt | 36 > >>> >>>>> +++---- > >>> >>>>> M .../typed-racket/types/base-abbrev.rkt | 12 ++- > >>> >>>>> M .../typed-racket/types/numeric-tower.rkt | 108 > >>> >>>>> +++++++++---------- > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> Would you mind explaining this a little more? It sounds > interesting, > >>> >>>> and > >>> >>>> the > >>> >>>> commit almost has my name in it. :) > >>> >>>> > >>> >>>> Neil ⊥ > >>> >>>> > >>> >> > >>> > > >>> > _________________________ > >>> > Racket Developers list: > >>> > http://lists.racket-lang.org/dev > >>> > >>> _________________________ > >>> Racket Developers list: > >>> http://lists.racket-lang.org/dev > >> > >> > > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev