Are routine objects guaranteed mutable & with dictionary?

[Steven D'Aprano]

On Sat, 05 Dec 2009 11:26:34 +0100, Alf P. Steinbach wrote:

> Regarding my terminology, "routine" instead "function" that everybody
> except you remarked on, it is of course intentional. [...]

I think you failed to realise that your use of the term was ambiguous. It 
wasn't clear that you were using "routine" as a noun, it seemed like you 
were using it as an adjective, that is, "routine objects" meaning 
"ordinary, common objects one would use routinely".

Your second example was:

(42).blah = 666

(which of course fails, because ints are immutable and you cannot add 
attributes to them). It isn't surprising that we failed to realise you 
were talking about callable objects when exactly 50% of your examples 
were not callable objects. Given the context, I think we were completely 
justified in thinking that you meant routine in the sense of commonly 
used.



> I use the term "routine" because I think the terminology influences what
> we can easily think of and what we therefore tend to use and/or discuss.
> In that respect I think people need to be educated to use more language
> independent, or Eiffel-like, or just historically original, terminology,
> because
> 
>    * "function" is misleading in itself (due to the hijacking of this
>    term in mathematics), and

"Function" in the mathematical sense dates back to Leibniz and Johann 
Bernoulli in the late seventeenth century. I'm not sure, but I think that 
may have pre-dated computers by a couple of years *wink*

http://www.gap-system.org/~history/HistTopics/Functions.html


>    * it gets worse when you can't reasonably talk about "co-functions"
>    or "function-like functions". :-)

"Co-function" is specifically a mathematical term, from trigonometry. 
Sine and cosine are co-functions, because they are related via 
complementary angles: the sine of an angle is equal to the cosine of the 
complementary angle.

That's the only definition Google has found:
http://www.google.co.uk/search?q=define%3Aco-function&ie=UTF-8&oe=UTF-8

Webster's dictionary agrees this is the only definition:
http://www.merriam-webster.com/dictionary/Cofunction

So I have no idea what you think a co-function (or cofunction) is, or why 
you can't talk about it.

As for "function-like functions", I can't think why you would want to use 
that term! If something is a function, it's obviously function-like, in 
the same way that cats are cat-like and chairs are chair-like.

If you want to talk about "function-like objects", or "function-like 
data", or "things that behave like functions but aren't actually 
functions", that is reasonable. We have names for such things: functor 
(from C++, different from functors in Haskell), or callable, or 
(verbosely, in Python) "any object with a __call__ method". But function-
like functions? That would just be a function.


> The devolution of terminology has been so severe that now even the
> Wikipedia article on this subject confounds the general concept of
> "routine" with the far more specialized term "sub-routine", which is
> just one kind of routine.

I'm not sure how to reply to that, since I'm not sure what you think a 
"routine" is in computing.

In my experience (which dates back to the early 80s), "routine" has never 
been anything but a generic term without any specific technical meaning. 
That is, one might talk about the "print routines" without caring whether 
they are external programs (say, printer drivers) or internal sub-
routines (functions, procedures, co-routines, methods, or even just a 
chunk of code you GOTO).


> It is of course OK with me that there is a
> default meaning, and that there are several different context
> dependendent meanings. I'm just mentioning this as an example that the
> terminology effectively constrains one's thinking, to the degree that
> even a moderately long encyclopedia article on the subject fails to
> mention or focus on the important aspects. 

What do you consider the important aspects of routines?


> Perhaps modern programmers
> should be forced to study Donald Knuth's TAOCP. Or something.

Perhaps. But not every car mechanic needs to be able to re-build an 
engine from scratch.

Besides, if every programmer had read Knuth, what reason would we have to 
feel superior to the code-monkeys? *wink*

I've-skimmed-parts-of-Knuth-and-am-therefore-superior-to-99%-of-coders-ly 
y'rs,

-- 
Steven