[Libre-soc-dev] liskov substitution principle and type assertions/annotations
lkcl
luke.leighton at gmail.com
Thu Aug 11 19:51:06 BST 2022
Couple of things.
Definition of LSP I saw, there is no inheritance tree, it is
the API that defines the substitution principle. Creating
Base classes *at all* and restricting types DIRECTLY and
fundamentally interferes with this extremely fundamental
principle on which python is fundamentally founded.
Everyone who uses python well (instead of complaining) knows
that float may be LSP substituted for int. You, Jacob, even
developed a small function that could be used either with
nmigen expressions or python numbers and if you had forced
types upon it that would not have been possible.
Nobody who uses python a lot gives a shit about how far down
the stack an Exception occurs. They want as little code in
as compact a form written quickly and readable quickly and
GENUINELY do not give a f*** about an int being accidentally
put as a float and an Exception occurring later rather than
earlier. Good python programmers know to look out for little
things like that, fix the problem and move on.
To say just because one person made a mistake and a float
got into the system therefore EVERY SINGLE F*****G FUNCTION
MUST without fail check every goddamn type, this is complete
overkill, a total overreaction, that compromises the power,
flexibility, compactness and pragmatism of python, and results
in vastly more code that 1 has to be written and 2 has to be
read.
If we truly wanted to piss about with types then we would
have started the entire HDL from scratch in c++ or probably
bluespec BSV.
Python is *designed* to be compact and *allow* flexibility.
Therefore please, *really*, stop putting types into the HDL,
and please stop putting type check assertions into functions.
Especially because your insistence on doing so, in combination
with the use of overly long function, class, and parameter
names, is resulting often in a massive 100% increase in code
size.
I routinely remove types that you insist on adding,
and fit what was formerly a four to six line function
definition onto a *single line* still under 80 Chars.
The only really appropriate place to use typechecking is when
a function arguments may be multiple different types. This
can be risky if the range of types was not predicted well enough
but it should be documented in the function docstring.
The appropriate place to declare an *advisory* on the expected
types for parameters is in the docstrings. We have unfortunately
been lax on that and it will come back and bite us.
By complete contrast the use of types in the Formal Correctness
additions to nmigen was wholly appropriate. There, a level
of strictness due to the mathematical foundations gives a
reassurance that people will not f*** up when using it, and
also when you were writing it.
It is a weird contrast that on one hand type checking is totally
appropriate but in another context it just gets fundamentally
in the way. it is what it is.
l.
More information about the Libre-soc-dev
mailing list