search

sile-typesetter / sile

The SILE Typesetter — Simon’s Improved Layout Engine
https://sile-typesetter.org
MIT License
1.67k stars 98 forks source link

Consider typechecking libraries that can be disabled #871

Open alerque opened 4 years ago

alerque commented 4 years ago

I noticed typecheck has a feature to disable itself to cut back on overhead. It might be worth looking into this for SILE's internal functions. Particularly with the new semi-object-oriented approach to measurements and other building blocks I keep wanting to add a bunch of checks to make sure we're getting the types we expect because it really eases the development process, but there is always an overhead cost in doing that and some places in the code are sensitive to this.

Whether we use typecheck or not it might be useful to build our own argument checking system that had a trigger to disable it. This would give useful errors by default but allow a "speed" mode that just tried to blunder through. This could be used either when not doing any Lua hacking and just rendering documents using already known code or in secondary/tertiary rendering passes (if we didn't have a type error in the first pass why would a third pass to rebuild the page numbers in the TOC cause one?)

alerque commented 3 years ago

Perhaps even more interesting is teal, a typed dialect of Lua that can either be run directly (using just a Lua loader shim) or transpiled to plain Lua with all the type annotations stripped.

OlivierNicole commented 3 years ago

Sometimes type information allows for more efficient compiled code, I wonder if that's part of the teal project.

alerque commented 3 years ago

I don't think that's the case here becaus Teal just targets plain Lua and passes that to the regular interpreter. I have seen some versions of LuaJIT that implement what you are talking about by taking shortcuts based on the type. That's also why we have some shims in, for example, our Length and Measurement objects and still have to do some awkward moves to support Lua 5.1.

The main thing I'm after is more correct code. A huge percentage of bugs to date have stemmed from type casting affecting us in ways we didn't expect. I think we can save both developer headache and end user frustration by being more strict about typing throughout, but I don't want it to come at the cost of introducing a constant stream of boilerplate type checks in every loop and function..

OlivierNicole commented 3 years ago

That does sound desirable.