[Date Index]
[Thread Index]
[Author Index]
Re: Mathematica daily such and so
*To*: mathgroup at smc.vnet.net
*Subject*: [mg115005] Re: Mathematica daily such and so
*From*: Daniel Lichtblau <danl at wolfram.com>
*Date*: Tue, 28 Dec 2010 06:49:27 -0500 (EST)
----- Original Message -----
> From: "Richard Fateman" <fateman at cs.berkeley.edu>
> To: mathgroup at smc.vnet.net
> Sent: Friday, December 24, 2010 3:11:55 AM
> Subject: [mg114958] Re: Mathematica daily WTF
> On 12/23/2010 12:55 AM, kj wrote:
> > In<ies9t9$aa9$1 at smc.vnet.net> Andrzej Kozlowski<akoz at mimuw.edu.pl>
> > writes:
> >
> >> Actually, there is nothing puzzling about this at all.
>
> You can only judge if something puzzles you, yourself.
>
> The general topic of naming and binding has been seriously mishandled
> over the years by WRI. Hence the original Block was found lacking and
> so Module was introduced. Module does not really do lexical scope
> since
> the names it makes up are accessible global symbols like foo$123.
I see no indication from this of any mishandling. Block is primarily a dynamic scoping mechanism. Module emulates lexical scoping. It is an imperfect emulation. That does not make it bad, and indeed there are situations in which symbol leakage is useful (some examples of such have appeared in this forum). I am fairly certain it is useful to have both types of scoping construct, so if anything the adding of Module was a really good idea.
Whether this allowing of symbol leakage (or other possibly accidental aspects of the implementation) was intentional I cannot say. The question of whether the implementation and semantics comprise the "best" possible way for Mathematica to emulate lexical scoping is not terribly important. I make this claim because there are no obvious grounds, of which I am aware, to regard it as bad and it seems to work well in practice.
> There are other issues, which have often been debated in the context
> of
> Lisp, a language from which Mathematica has borrowed some ideas.
>
> For example,
> Sin=1234 is forbidden since Sin is "protected".
>
> Block[{Sin=1234}, Sin] returns 1234 since the local variable Sin is
> different from the global Sin, and is not protected, explaining this
> WTF, perhaps more simply.
>
> Indeed, Block[{Sin = 1234}, Sin [Pi]] returns 1234[Pi]
>
>
> but wait, there's more.
>
> Block[{Sin}, Sin[Pi]]
> returns 0, because local Sin evaluates to global Sin which then
> is the usual sine function.
>
> Module[{Sin}, Sin]
> returns Sin$1317 or something like that.
>
> Block[{Sin = 1234}, Sin [Pi]] returns 1234[Pi]
>
> Now of course it will not puzzle Andrzej, but here is a little
> test that you can run on (a) your brain. (b) your Mathematica.
>
> Block[{Sin = notSin}, Block[{Sin}, Sin[Pi]]]
> Block[{Sin = notSin}, Module[{Sin}, Sin[Pi]]]
> Module[{Sin = notSin}, Module[{Sin}, Sin[Pi]]]
> Module[{Sin = notSin}, Block[{Sin}, Sin[Pi]]]
>
> You might consider as possibilities:
> 1. 0
> 2. notSin[Pi]
> 3. Sin$1325[Pi] your number may vary//
>
> ..............
> In Common Lisp, the question of whether a local symbol
> (e.g. sort of like a Module variable)
> has the global property list of the symbol that
> prints the same is resolved as: No.
> does it have the global property of the function definition of
> the symbol with the same name: No.
>
> However, if you use a name as a function, e.g. Sin, then regardless
> of local value bindings, you get the function.
> thus
> (let((sin 1234))(values (sin pi) sin))
> returns the values 0.0 and 1234. (actually, not 0.0 but 10^(-16) apx)
>
> So Common Lisp is a 2-lisp in this respect. functions and values
> are separate. Scheme variety is a 1-lisp requires function=value.
>
> It seems that if Mathematica were a lisp, it would be closer to a
> 1-lisp, though if it were really lisp, it would have a much different
> and far simpler evaluation mechanism. Lisp has "quote" and "eval".
> Instead of all the Hold, Release, Eval, and friends. In Lisp, the
> explicit use of eval is almost never used except by novices who are
> usually making mistakes. Whether Mathematica's evaluation is the
> right thing is presumably now moot. Remember that "evaluate until it
> stops" makes x=x+1 hurt.
Emulation of infinite evaluation (sans side effects) will do that. As it ought. So what?
> RJF
I don't see anything here that shows bad behavior. If you are claiming that one or more items above are bad, feel free to elaborate as to what they might be. What I do see is that Mathematica has more complicated semantics than Lisp. This can be a cause of confusion but it is hardly unexpected.
Package design, modularity, and context manipulation might be another matter. That stuff gets confusing, and I'm never sure there is a solid reason behind it. Bad design for emulation of encapsulation features in other languages? Bad documentation? Both? Neither? I don't know. As variable and function encapsulation go, this does seem to catch more people (myself included) in more ways during routine usage than anything I've seen mentioned regarding Block, Module, Attributes, or localization of variables in this and other recent threads. I mention this mostly to motivate my main point. To wit, I think the present thread is wildly off the mark from anything resembling either general usage of Mathematica, or a productive line of enquiry.
Daniel Lichtblau
Wolfram Research
Prev by Date:
**Re: Mathematica daily something or other**
Next by Date:
**Re: VectorFieldPlot problem.**
Previous by thread:
**Re: Mathematica daily such and so**
Next by thread:
**Re: Mathematica daily something or other**
| |