Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2001
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2001

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

Search the Archive

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.




  • Prev by Date: RE: Surface graphics (Plot3D) colouring question
  • Next by Date: Re: scope all wrong? in Mathematica 4.1
  • Previous by thread: Re: scope all wrong? in Mathematica 4.1
  • Next by thread: Re: scope all wrong? in Mathematica 4.1