Re: Types in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg62296] Re: Types in Mathematica*From*: John Doty <jpd at whispertel.LoseTheH.net>*Date*: Sat, 19 Nov 2005 23:18:25 -0500 (EST)*References*: <200511120833.DAA19252@smc.vnet.net> <43762529.7060603@math.umass.edu> <dl8s4g$n41$1@smc.vnet.net> <dl980q$r2a$1@smc.vnet.net> <200511140805.DAA00041@smc.vnet.net> <dlc96b$m81$1@smc.vnet.net> <dlhibt$5ki$1@smc.vnet.net> <dlkc76$pq0$1@smc.vnet.net> <dln160$geq$1@smc.vnet.net>*Sender*: owner-wri-mathgroup at wolfram.com

Steven T. Hatton wrote: > John Doty wrote: >>Functional programming is not really built into the Mathematica >>*language* at all: it is a matter of convention. For example: >> >>In[10]:= x_[s] ^:= Sin[x] >> >>In[11]:= Pi[s] >> >>Out[11]= 0 >> >>Try defining an "argument" that operates on its "function" in any other >>language. > > > I can pass a function object to another function object in C++. The passed > functor (argument) can certainly modify the state of the object to which it > is passed. > > That's not what happens here. s is never "passed" to Pi: no transformation associated with Pi ever sees s. Instead, the evaluation engine recognizes a transformation, associated with s, that it can apply. Analogies are only useful within bounds. The caloric theory of heat is perfectly good for some problems, but it is folly to push it too far: in the end you have to understand heat on its own terms, not by analogy with a fluid. In the end, you have to understand a tool like Mathematica on its own terms: pushing analogies too far will simply mislead you. And if you insist on understanding by analogy, you'll never know what "too far" is. -jpd

**References**:**Types in Mathematica***From:*"Steven T. Hatton" <hattons@globalsymmetry.com>

**Re: Types in Mathematica***From:*"Steven T. Hatton" <hattons@globalsymmetry.com>