[ prog / sol / mona ]

prog


Typed racket

1 2018-11-01 04:56

racket/base hello world: 1.2MB
typed/racket/base hello world: 20MB

Apparently they did not realise that type-checking should only be a compile-time stage, huh?

2 2018-11-02 01:04 *

Apparently they did not realise that type-checking should only be a compile-time stage, huh?

What about eval?

3 2018-11-03 01:14

There are basically two levels involved: one of them is 'correctness'. To ensure the code is correct when passing the typed/untyped barrier (lest you can't call untyped racket), runtime checks need to be inserted in some specific circumstances. This usually only happens when the type can only be ensured at runtime, i.e. when you pass the typed/untyped barrier or when the type depends e.g. on eval or otherwise, user input.

4 2018-11-03 09:50

>>2
So, just like the dynamically typed version?

5 2018-11-03 10:06

>>4
Basically what >>3 said.

The size of your executable is due to the fact that racket has to embed all the compile-time dependencies of typed racket.

With constructs like eval (or user input) it's not enough to check types at compile-time.

6 2018-11-03 22:15

>>3
>>5
Details on performance impact can be found here.

http://www.ccs.neu.edu/home/types/publications/gradual-dead/pre-treatment.pdf

7 2018-11-04 02:38

>>6
That's very sad, didn't the typed racket guys say the exact opposite at one point? They claimed 100x+ speedups by using typed racket vs untyped.

8 2018-11-04 15:26

>>7

That's very sad, didn't the typed racket guys say the exact opposite at one point?

Efficient gradual typing is still an active area of research. Also, see section 5.1 on the validity of their findings.

They claimed 100x+ speedups by using typed racket vs untyped.

And they probably did get these speedups when they replaced a large body of untyped code with typed code without relying on untyped libraries. The issue is that gradual typing has to work, well, gradually. Gradual typing won't be viable as a speedup strategy until this is improved. If runtime costs are too high, gradual typing won't be viable as a correctness strategy either.

9 2018-11-05 23:12

How big is haskell type checking hello world ;^)

10 2018-11-06 01:40 *

>>9
The angry Norwegian already covered this kind of thing over a decade ago.

https://www.xach.com/naggum/articles/search?q=Re%3A+size+of+executables%3F&sort=of

11


VIP:

do not edit these