Re:Types will be part of Ruby 3 stdlib source
by ghostwriter on Friday April 19, 2019 @09:50AM
(#19699581)
It's because PyPy relies on traced runtime statistics for optimizations via inlining. There's another approach where you translate your typed program into a lower-level target language and compile it into a native binary. See https://github.com/mypyc/mypyc and https://github.com/cython/cython/wiki/Python-Typing-Proposal
Re:Types will be part of Ruby 3 stdlib source
by pjmlp on Friday April 19, 2019 @08:09AM
(#19698855)
Dart has long changed.
Re:Types will be part of Ruby 3 stdlib source
by readittwice on Friday April 19, 2019 @09:23AM
(#19699374)
True, that's why I wrote "Dart had".
Dart had gradual types but didn't enforce them at runtime because of performance. The PyPy devs don't believe that type annotations help them for performance (http://doc.pypy.org/en/latest/faq.html#would-type-annotation...). Also there is no JS engine that uses TypeScript annotations so far to improve performance.
Types are usually on the wrong boundary: e.g. Integer doesn't state whether that value fits into a register or is a Bignum.
Also: Aren't some type checks quite expensive? So more expensive than a simple map/class/shape check? E.g. passing an array from untyped code to a signature with something like `Array<Integer>`. Wouldn't a runtime that verifies signatures have to check all elements in the array to be actual Integers?