Re: scope all wrong? in Mathematica 4.1
- To: mathgroup at smc.vnet.net
- Subject: [mg31851] Re: [mg31827] scope all wrong? in Mathematica 4.1
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Fri, 7 Dec 2001 05:56:44 -0500 (EST)
- Organization: University of California, Berkeley
- References: <3E9936FC-E9F0-11D5-9155-00039311C1CC@tuins.ac.jp>
- Sender: owner-wri-mathgroup at wolfram.com
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.