Re: What's the name for this?

From: Edward G. Nilges (
Date: 04/24/04

  • Next message: Roger Willcocks: "Re: Implementing strstr"
    Date: 23 Apr 2004 17:57:04 -0700

    Chris Dollin <> wrote in message news:<c6atlm$ajc$>...
    > Edward G. Nilges wrote:
    > > Chris Dollin <> wrote in message
    > > news:<c62r8t$hfh$>...
    > >> Edward G. Nilges wrote:
    > >>
    > >> > Willem <> wrote in message
    > >> > news:<>...
    > >> >> TLOlczyk wrote:
    > >> >> ) One caveat. You can only use this technique on functions with no
    > >> >> ) side-effects ie you need for the function to return the same value
    > >> >> ) each time you call it.
    > >> >>
    > >> >> If a 'function' has a side-effect, then it isn't really a funciton, is
    > >> >> it ?
    > >> >
    > >> > In fact, these types of corrections may be objectively viewed as that
    > >> > which deprives working programmers of a language for talking about
    > >> > programs.
    > >>
    > >> Using the term "function" to mean "function, as in mathematics, ie
    > >> without side effects" doesn't deprive working programmers [as opposed
    > >> to what other kind?] of language for talking about programs, since
    > >> the term "procedure" can do just fine - not to mention "method",
    > >> or "[sub-]routine".
    > >>
    > >> The notion of "side-effect-free procedure" is common and useful - what
    > >> name would you propose that we give it?
    > >
    > > How about "side effect free procedure"?
    > Common, useful notions should have short names. "Side-effect-free
    > procedure" is not short [and arguably not a name either].

    A function (that which returns a value) should have no side effects
    except returning a value where that is "a side effect of order 0". But
    to DEFINE a function as a side-effect-free procedure foregrounds what
    is accidental about a function and not necessary. What's necessary is
    it has a value which it returns.
    > > The question is whether it is essential to a function that it returns
    > > a value, or whether it has no side effects.
    > No; the question is what distinctions are usefully and commonly drawn.

    By whom? I suggest that there is no one community of mathematicians or
    anyone else whose language should be controlling, only structures used
    within multiple communities and the fact is that in programming
    considered as applied mathematics, a function (1) returns a value and
    (2) may, unpleasantly, have side effects.
    > > Platonist philosophers of mathematics, including unconscious
    > > Platonists, seem to want to declare that we must "know" whether the
    > > "function" has "side effects", but a more evolved philosophy of
    > > mathematics might not "care".
    > Some "people" might "wonder" why you have decorated so many "words"
    > with "scare" quotes in the that paragraph. As for what a more-
    > evolved philosophy of mathematics might or might not do with respect
    > to programming-relevant terminology, when it matters I'll consider
    > it.

    We have a philosophy of mathematics whether we want to or not, and
    Platonism produces bugs because of its demand that everything be known
    and available.
    > In practice we often *do* want to know whether a function [in the
    > weak sense] has side-effects as well as some return values, because
    > it matters. So a term that means "returns a result, has no side-effects"
    > to contrast with "returns a result, may have side-effects" is useful.
    > If you pick "function" for the side-effect-free case, "procedure"
    > works for the may-have-side-effects case.

    The problem is that the usage differs from actual practice.
    > > Calling "that which returns a value" a "procedure" or a "method" is
    > > unacceptably imprecise in practice because in practice you care more
    > > that the thing returns a value.
    > If you care that it returns a value, you often care what *kind* of
    > value it returns, but you don't rely on the term "function" to tell
    > you that - you look at its signature. Similarly to know what arguments
    > it takes. Whether a procedure happens to return no results, one result,
    > three results, or a variable number, is part of its signature. I'll
    > grant that you might want a term for the common special case of a
    > procedure with exactly one result.
    > [And yes, when I say "returns N results", I mean "returns N results",
    > I don't mean "stuffs N [or N-1] results in some by-reference arguments".]


    > > This is obscured by the demotic
    > > popularity of the C language, which was for programming an
    > > intellectual disaster, because in C all procedures are forced to
    > > return a value.
    > First, not all C procedures are forced to return a value, not since
    > 1989. Procedures [traditionally called "functions" in C, oh well]
    > with return-type void don't return any value.
    > Second, this is hardly an "intellectual disaster"; it's little more
    > than a quirk.
    A quirk that is today considered as representative of good practice
    and used in place of Pascal and Algol IS an intellectual disaster
    because quirks obscure the truth.
    > > This places the monstrous void on a throne of incoherence.
    > Yeah, "void" has multiple meanings in C - "no result", "no arguments",
    > "base type for generic pointers". Quirky. "Throne of incoherence"
    > is putting it a tad strongly - if you use purple prose for trivia
    > like C's "void", what are you going to use for the exciting parts
    > of C++ and Java and perl?

    As to C++, words fail. As to Java and perl, their developers did a
    heroic job of cleaning the intellectual slag heap dumped on the
    highway of progress by C, to wax purple.

  • Next message: Roger Willcocks: "Re: Implementing strstr"