[Date Index] [Thread Index] [Author Index]

Re: scope all wrong? in Mathematica 4.1

• To: mathgroup at smc.vnet.net
• Subject: [mg31857] Re: [mg31827] scope all wrong? in Mathematica 4.1
• From: Andrzej Kozlowski <andrzej at tuins.ac.jp>
• Date: Fri, 7 Dec 2001 05:56:53 -0500 (EST)
• Sender: owner-wri-mathgroup at wolfram.com

Of course you are right that I am a mathematician by training and not a 
computer scientist. Clearly our perspectives on programming languages 
are different: I tend to look at them as tools, to be used in doing 
mathematics, not as formal systems to be studied. In  judge a 
programming language by its usefulness and not not by such matters as 
consistency and so on. What can be "proved about it", is usually less 
interesting to me, at least in my capacity as a user of a programming 
language. Of course there are situations when it is no so. It so happens 
that I first learned Lisp from reading Greg Chaitin's "Algorithmic 
Information Theory". Before that I had only only had used Algol and 
Pascal which I learned as an undergraduate, and when I read Chaitin's 
book I was amazed there could be a programming language that was so 
perfectly consistent and well defined that one could prove theorems 
about it. That is indeed very beautiful, but hardly useful for doing the 
sort of mathematics I am really interested in. The whole situation 
reminds me of the traditional division in mathematics between these 
mathematicians who consider foundations of mathematics as an important 
and central subject and those who think of it as something totally 
unimportant. Suppose an unresolvable flaw was discovered in the 
foundations of Mathematics, say a basic inconsistency in all known 
axioms of set theory. What would be the reaction of people studying 
partial differential equations? Most would just shrug their shoulders 
and go on doing what they were doing, and in my opinion would be quite 
right to do so. These subject do not rest on the "foundations", it's 
only the people who who work on foundations who flatter themselves that 
it is so. You talk of mathematics in terms of "axioms". Of course there 
are many mathematicians who think in this way. But there are many more, 
including myself (and I mean pure mathematicians dealing with abstract 
objects like manifolds or complexes) who hardly ever mention this word 
in their work.

So my reaction to your examples and to most of your comments is that 
them may well be true but are hardly relevant to me or the vast majority 
of people who use Mathematica. You say that the fact that something is 
documented and called a "feature" does not stop it being a bug. But that 
is only true if that "bug" prevents you from doing something you might 
want to do. When the manual says "don't do it this way, do it that way", 
the argument that other programs do it the first way and so not being 
able to do it that way must be a bug, does not seem to carry much weight 
to me.

I find Mathematica more useful than Common Lisp because I can, for 
example, combine Groebner basis computations, with graphics and 
evaluation of integrals, all in the same program. Of course these things 
could be added to  Lisp, but they are not. Moreover, the rule based 
programming style of Mathematica is very much more efficient for the 
kind of things I do, most of the time. Let me make this concrete. At 
this time I doing research which involves  computing invariants of 
actions fo finite groups on certain polynomial rings. I have written a 
"package", or rather just a collection of functions, defining the 
Steenrod operations, Dickson invariants and so on. I use this together 
with the built in GroebnerBasis and other polynomial algebra package. 
All of this just in about two printed pages. I also happen to have a  
Lisp program which does basically the same thing. It's more than 10 
pages long and is most of the time slower. There are countless other 
examples of this kind. In fact I only use Lisp when I need to do 
something that will require huge amounts of memory, because in such 
cases Lisp's recursive programming seems sometime the only way to go. 
But this has nothing to do with the consistency of Lisp and Mathematica 
and nothing to do with scoping.

So to sum up: I consider the  examples that you sent to be of some 
theoretical interest and 0.  practical importance. TO justify this view 
I looked at some of my hundreds of Matheamtica notebooks to check how 
often I used Block and Module. It was I as expected, almost exclusively 
when writing something for the mathgroup. I am now not even sure how I 
came be indoctrinated with the idea that one should do that! The 
programs I  write for myself consist of lots of short, often one line 
function definitions and function calls.  In fact I often use global 
variables and Clear them afterwards. It seems to me that this is the 
natural way to use Mathematica and I expect that most users do the same. 
Given that, is it surprising that I consider yor message of little 
importance. Maybe Mathematica scoping is "all wrong" but if so then 
"scope" is hardly an important aspect of Mathematica. Suppose it could 
be "fixed", would it make Matheamtica a more useful tool? I doubt it. 
Moreover, any human and other resources devoted to this task would have 
to be diverted form other things, like mathematical applications. If one 
has to choose between improving Mathematica scope and its ability to 
solve differential equations, how many users would choose the former? 
Very few I believe. I think in the end this is the central issue. Of 
course I would like Mathematica to be perfect in all respects, but 
fixing the "foundations" is less important to me than expanding its 
frontiers. Like mathematics, Mathematica is not a vertical structure 
that can be brought down by some weakness of its foundations ( or at 
least not this particular weakness).


Andrzej Kozlowski
Toyama International University
JAPAN
http://platon.c.u-tokyo.ac.jp/andrzej/




On Friday, December 7, 2001, at 02:01  AM, Richard Fateman wrote:

>
>
> Andrzej Kozlowski wrote:
>
>> This sort of arguments seem to be a regular feature on this list. I do 
>> not feel like going into detail because I remember all this having 
>> been done before more than once. There are however  three general 
>> points that I would make.
>> 1) All the "unexpected" outputs are exactly as would be expected by 
>> anyone who has a fair grasp of the Mathematica language and can be 
>> supported by the documentation.  Therefore they can't be called bug, 
>> at least not in the sense that I understand the term.
>
>
> Documenting a bug as a feature does not remove it, in my opinion.
> My guess is that your formal training is not in computer science,
> and that you have not taken a course in (say) design of programming
> languages.
>
> In mathematics it is possible to construct formal systems based on
> any set of non-contradictory axioms, and there is only a momentary
> pause in the stream of publications when someone points out that
> the defined system is useless, or perhaps vacuous.  A set with no
> elements has many properties, and if you didn't realize it was empty,
> you could have something quite interesting!
>
> In programming, there is not so much that is arbitrary.  We don't
>  want people to be surprised by the consequences.  Sometimes there are
> legitimate choices in design, based on different perspectives of
> (say) scope: which is most useful/efficient.  Sometimes there are
> just "bad" designs.  I think of these as really bad bugs, especially
> when they are defended.  (Maple, for a long time, had some such
> bugs.  To their credit, they eventually fixed them. Probably because
> one of the designers left the company.)
>
> (This is not to say
>> that there are no bugs in mathematica, it certainly has its fair 
>> share. Just that none of these are.)
>
>
> Certainly we can agree to disagree here.
>
>
>> In fact the first two cases are Mathematica "standard errors", 
>> discussed in this group a countless number of times . If a Mathematica 
>> beginner came up with them I would refer him to the Mathematica Book. 
>> The other examples are more subtle but highly contrived. In the 
>> unlikely event that that a beginner would be troubled by them my 
>> reaction would be to say "why on earth do you want to do that?".
>
>
>
> Certainly you are familiar with the importance of counterexamples in 
> mathematics.
> If someone proposed a new axiom system for geometry, and you showed that
> it lead -- in certain singular instances -- to contradictions, then
> you would have a valid objection to that system.  You would probably
> not have much confidence in anything proved in that system.
>
> If someone proposed a new programming language and I showed that it
> lead -- in certain singular instances -- to nonsense,  then I would
> have a valid object to that language.  I would not have much confidence
> in anything programmed in that system.
>
>
>
>> 2) One can certainly argue about the good and bad points of the design 
>> of a programming languages. However, to a large extent this is a 
>> matter of what one is used to, how and how often one uses a language 
>> and of personal taste.
>
>
> To some extent this is true.  Just as in mathematics one can use
> a notation  f'(x)  or d/dx(f(x)).
>
> For example, you have written on the subject of Block
>> and Module before, and I have found that some of the things that you 
>> criticize are in my opinion among their strongest points, allowing 
>> many constructions that are difficult to achieve in other programming 
>> languages.
>
>
>
> I don't know what other programming languages you are referring to here.
> You mention Common Lisp, which allows a far more complete and consistent
> programming perspective. If you are saying Mathematica as a programming
> language is better than Common Lisp, I think you are being blinded by
> application programs, and superficial syntax. These can of course be
> added to Common Lisp, and it does not require breaking the semantics
> to do so.
>
>
>> 3) I can imagine that there may be good  reasons for being interested 
>> in translating between different programming languages. I do not know 
>> much about that.
>
>
> Often this is appealing because people say "mathematica is too slow,
> can it be translated into C"  or  "I would like to run my Maple program
> along with someone else's Mathematica program".
>
>> However, as a matter of practice I find "translating" a bad idea. I 
>> use two languages, Mathematica and Common Lisp, the first very often 
>> and the second when really needed,  and I make an effort to 
>> consciously avoid trying to translate between them since this is the 
>> surest route to inefficient programming. Both languages have their 
>> unique strengths and are ideally suited for different purposes. The 
>> Mathematica language is certainly unlike any other but I really do not 
>> see why this is a bad thing. And after all, as you yourself have 
>> written, one is always always free not to use it. Since you have 
>> already made this point  what is the point you are trying to make now?
>
>
> I am continually surprised at how bad the design is in respect
> to certain programming language issues. As you know, I wrote a
> parser / partial evaluator for Mathematica  (MockMMA) in Lisp.
> I have not run these examples in it, but I expect that it will
> either (a) operate in the same way as a consequence of my having
> programmed the order of evaluation and binding in the same way
> as Mathematica,  or (b) operate in a different way, reflecting
> my (mis)understanding at the time of how the simulation of parameter
> binding by pattern matching is supposed to work.  My expectation
> is that at time time I wrote MockMMA, my understanding of
> (a) the syntax
> (b) the pattern matcher
> (c) the evaluation
> was as thorough as any but a handful of people.
> That is generally what happens when one implements a system:
> all the details must be tied down.
>
> As programming language designers, we are not constrained
> to physical reality (as is the case with some physicists).
> we are not constrained to study actual biological animals
> and plants (as is the case with some biologists).
> We can construct our own systems.  Somewhat like mathematicians
> but with a different esthetic sense.
>
> The language design of mathematica, presumably done by
> Wolfram, has many interesting features.  It is possible
> that these same features could be assembled in a system
> that does NOT botch scope.  MockMMA allows one to experiment
> with such changes, though frankly no one (including myself)
> has pursued "a new Mathematica evaluation mechanism" using
> this tool.
>
>
> I do not know how the system would have come out if Wolfram
> had (for example) really understood lambda calculus or
> lexical scope.  If he had read the Abelson-Sussman book
> Structure and Interpretation of Computer Programs,
> I think Mathematica's language would make more sense.
> As it is, Wolfram picked up some of these ideas but did not, I
> think, understand them.
>
>
>
>