4 ms·

Toit is optionally typed, and supports type annotations. Type annotations for locals, fields, and globals are written with a trailing `/Type`. Return types are

Toit is optionally typed, and supports type annotations. Type annotations for locals, fields, and globals are written with a trailing `/Type`. Return types are written with `-> ReturnType`. See https://github.com/toitware/toit-lsm303dlhc/blob/main/src/accelerometer.toit https://github.com/toitware/toit-lsm303dlhc/blob/main/src/ac... for a file I recently edited. When a type annotation is written, the compiler enforces it. It uses it for static optimizations, and dynamically checks that the type is correct. When a type can be null, it has to be suffixed by `?`.

pansa2 5y ago
> dynamically checks that the type is correct How thorough is this? Beartype is also on the front page right now, and its README contains an example of dynamic type checking in Python that takes over an hour to run [0]. Is Toit able to avoid being that slow? [0] https://github.com/beartype/beartype#why-should-i-use-beartype https://github.com/beartype/beartype#why-should-i-use-bearty...
- floitsch 5y ago
  Toit doesn't have generic types yet. This limitation means that the dynamic checks are very fast. Since these checks also allow some optimizations, the cost of the dynamic checks is maybe 10-15%. And that's before doing a global type-inference, which should remove many of the checks.
IshKebab 5y ago
Ah ok, I couldn't find anything about that in the docs but maybe I missed it. Interesting syntax choice when everyone else is going with `name: type`.
keyle 5y ago
side question, bit of a general question too... how do you make it fast with having optional type annotations?
- floitsch 5y ago
  We get a lot out of having static classes and methods that can't change dynamically. This allows us to use the selector-based row displacement technique for building a compact method dispatch table. (See https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.8713&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29...) Many small decisions help keeping the system fast. The memory layout, the bytecodes, the FFI interface, ... Separating the compilation process from the running process obviously also helps. It gives us the option to do slower optimizations before-hand, and not pay for them at runtime. (Independent of the fact that the ESP32 wouldn't be able to do big optimizations anyway). This is actually an area we haven't really spent too much time on yet: optimizations. The current compiler doesn't even do inlining yet. The speed of Toit was never really a problem, and we preferred to spend time elsewhere. Eventually, we will definitely do more there again.

pansa2 5y ago

> dynamically checks that the type is correct How thorough is this? Beartype is also on the front page right now, and its README contains an example of dynamic type checking in Python that takes over an hour to run [0]. Is Toit able to avoid being that slow? [0] https://github.com/beartype/beartype#why-should-i-use-beartype https://github.com/beartype/beartype#why-should-i-use-bearty...

floitsch 5y ago
Toit doesn't have generic types yet. This limitation means that the dynamic checks are very fast. Since these checks also allow some optimizations, the cost of the dynamic checks is maybe 10-15%. And that's before doing a global type-inference, which should remove many of the checks.

IshKebab 5y ago

Ah ok, I couldn't find anything about that in the docs but maybe I missed it. Interesting syntax choice when everyone else is going with `name: type`.

keyle 5y ago

side question, bit of a general question too... how do you make it fast with having optional type annotations?

floitsch 5y ago
We get a lot out of having static classes and methods that can't change dynamically. This allows us to use the selector-based row displacement technique for building a compact method dispatch table. (See https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.8713&rep=rep1&type=pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29...) Many small decisions help keeping the system fast. The memory layout, the bytecodes, the FFI interface, ... Separating the compilation process from the running process obviously also helps. It gives us the option to do slower optimizations before-hand, and not pay for them at runtime. (Independent of the fact that the ESP32 wouldn't be able to do big optimizations anyway). This is actually an area we haven't really spent too much time on yet: optimizations. The current compiler doesn't even do inlining yet. The speed of Toit was never really a problem, and we preferred to spend time elsewhere. Eventually, we will definitely do more there again.