Functional programming

[Ben Finney]

Gregory Ewing <greg.ewing at canterbury.ac.nz> writes:

> Just because the compiler *can* infer the return type doesn't
> necessarily mean it *should*. When I was playing around with
> functional languages, I ended up adopting the practice of always
> declaring the types of my functions, because it helps the *human*
> reader.

Sure. In a duck-typed language like Python, it is still helpful to the
human reader to document the *meaning* of each parameter, beyond what is
indicated by the name. We have reStructuredText and docstrings for this
purpose.

    def frobnicate(flang, splets, queeble=False):
        """ Righteously frobnicate the flang.

            :param flang: A file-like object, opened for reading.
            :param splets: A sequence of unprocessed Splet instances.
            :param queeble: If ``True``, re-vitrify the flang during
                frobnication.
            :return: A new list of processed Splet instances.

            The flang is frobnicated according to the Weebly-Ruckford
            algorithm.

            """
        for line in flang:
            …

> (It also helped the compiler produce comprehensible error messages in
> the event of a type error.)

Docstrings in the above reStructuredText field-list style will be
processed by Epydoc <URL:http://epydoc.sourceforge.net/fields.html>.

Other styles of specifying parameters in an mechanically-extractable
form are also used, by Sphinx for example. The point is, we have
docstrings, and conventions in docstrings for specifying parameters for
the human reader *and* for automated tools to read.

-- 
 \            “… Nature … is seen to do all things Herself and through |
  `\         herself of own accord, rid of all gods.” —Titus Lucretius |
_o__)                                                 Carus, c. 40 BCE |
Ben Finney