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