[racket-dev] Typed versions of untyped collections

From: Neil Toronto (neil.toronto at gmail.com)
Date: Mon Dec 17 18:39:15 EST 2012

On 12/17/2012 04:32 PM, Matthias Felleisen wrote:
>
> On Dec 17, 2012, at 6:10 PM, Neil Toronto wrote:
>
>>>>
>>>> `plot' is written in untyped Racket. There's no performance problem with typed plots at all; in fact, using `plot/typed' from TR code ends up checking exactly the same contracts for the same plots. `plot/typed' is just another end-user that happens to re-export everything with types attached.
>>>
>>> I don't understand this last part at all. You have
>>>
>>> -- an untyped file M
>>> -- a typed file T that imports M and re-exports everything from there with types
>>>
>>> How can it possibly be the case that a client C imports T and does NOT pay for the contracts that T's types impose on the call chain?
>>
>> That would only happen if client C is untyped. I wouldn't expect an untyped client to (require plot/typed), but I suppose it could happen.
>
>
> Wait. This is the line I don't understand:
>
> C is TYPED. It requires T.
> T is TYPED. It requires M.
> M is UNTYPED.
>
> If c in C calls t in T, this first call does not add any overhead. OK.
> But t is really m from M obtained with a require/typed. [Alternatively, it is redefinition that calls such a function.]
>
> It is this call from t to m that imposes the overhead.
>
> Why are you saying that "There's no performance problem with typed plots at all"?

Oh! Oh, right... I totally forgot that `require/typed' wraps things in 
contracts. Duh.

Yes. So plotting in Typed Racket goes through two contract barriers. 
It's a small performance hit compared to the rest of the rendering 
pipeline. But it's a performance hit. We can carry on now.

Neil ⊥


Posted on the dev mailing list.