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

```

• Prev by Date: Re: Types in Mathematica
• Next by Date: Re: Random Normal deviates within compiled function?
• Previous by thread: Re: Types in Mathematica
• Next by thread: Re: Types in Mathematica