Talk:Evaluate binomial coefficients: Difference between revisions
Talk:Evaluate binomial coefficients (view source)
Revision as of 10:37, 24 February 2019
, 5 years ago→Are type hints a good idea for RC Python examples ?
(→Please desist from deleting Functional Python examples: Convergence?) |
|||
Line 137:
: For the human reader whose HM comments have been deleted, the parseable type hints to the '''mypy''' checker have a '''poorer signal to noise ratio'''. Cognitively redundant 'Callable' names are multiply inserted where HM needs none, each also bringing 4 additional square brackets. In some instances type names require lower case, in others upper case. The simply polymorphic HM `a` (any type) is replaced by the more verbose '''Any''' (or even '''typing.Any''').
:: For example, given an '''enumFromTo''' function which handles enumerations of any enumerable type,
:: (e.g. Char or Bool enumerations '''['a' .. 'z']''', '''[False .. True]'''
:: as well as Int and Float enumerations '''[1.. 10]''', '''[1.5 .. 10.5]'''),
:: The HM comment: '''enumFromTo :: Enum a => a -> a -> [a]'''
:: is both less noisy and more informative to the reader than the mypy type hint:
:: '''def enumFromTo(m: Any) -> Callable[[Any], List[Any]]:'''
:: Which has no semantics for indicating a restriction to enumerable types ...
: Additionally, the scope for Rosetta comparison is diminished – the links between implementations of standard abstractions across different languages are weakened and made less directly visible and comparable. (There are many Haskell, JavaScript, Python and ApplesSript examples on RC which use the same function name, and the same Hindley Milner type comments, for a given mathematically founded abstraction - we can learn a lot about a language, on a fine scale, by comparing these implementations).
| |||