Are routine objects guaranteed mutable & with dictionary?

[Alf P. Steinbach]

* 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.

One example and one counter example. I can't think of why anyone should lump 
these together as examples of the same thing.


> Given the context, I think we were completely 
> justified in thinking that you meant routine in the sense of commonly 
> used.

Bah.


>> 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*

Yes, that was my point. 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.

Right. That was my point. Wink. Heh heh. :-) Try substituting "routine". That 
is, s/function/routine/g.


> As for "function-like functions", I can't think why you would want to use 
> that term!

See above. ;-)


> If something is a function, it's obviously function-like, in 
> the same way that cats are cat-like and chairs are chair-like.

Right, that was my point.

Including that with the C/Python terminology it isn't.


> 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.

Right.


>> 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.

See the Wikipedia article and allow for some confusion on the part of the 
authors. Or, if you have TAOCP handy, look it up there. However, you may 
disregard Donald Knuth's definition of "reel time" :-), I'm not invoking him as 
an authority on terminology, just a handy accessible source for the general 
meaning of "routine" (disclaimer: haven't looked it up for this posting, so I 
can't guarantee that you'll find it, although as I recall in volume I).


> 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).

Well, my experience is perhaps a bit longer, but not much. And you're on the 
right track. It's a more general term, *and* it has context dependent meanings.


>> 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?

One of the most important aspects is the invocation model. There are many such. 
Sub-routines and co-routines are the two most common special cases, but for a 
little more general way of thinking about how routines are invoked and 
communicate, if you can find a copy of Patrick Henry Winston's "Artificial 
Intelligence" nearby, as I recall he discussed some other options in a very 
clear way (illustrated with Lisp examples).


>> 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,

He he. :-)


Cheers,

- Alf