Re: Re: declaring integers

*To*: mathgroup at smc.vnet.net*Subject*: [mg13125] Re: [mg13063] Re: declaring integers*From*: Joe Oswald <jaoswald at fas.harvard.edu>*Date*: Tue, 7 Jul 1998 03:44:28 -0400*Sender*: owner-wri-mathgroup at wolfram.com

On Sun, 5 Jul 1998, David Withoff wrote: > I didn't understand your discussion here, and the parts that I think I > understand don't seem to be correct. Perhaps if I describe my concerns > you can offer some clarifications. > > > When one types "a + b" in most languages (e.g. Fortran, C, Lisp "(+ a > > b)"), one is referring to a mechanical procedure where some item, named > > a, will be added to another item, named b. The nature of that procedure > > will depend on whether a and b are small-sized integers or > > floating-point numbers, or rational numbers, or large-sized integers. > > It also doesn't make much sense if a is a string and b is a number. > > I.e., it matters what "type" the "variables" are. > > That is what happens in Mathematica too. If you enter a+b, that invokes > a mechanical procedure that will depend on what a and b are. Well, no. If a and b don't have defined values, nothing gets added. The pattern is simply returned: In[1] := a + b Out[1] = a + b I.e. nothing is really "added". You might say that this is what addition "means" for things which are just symbols, but this misses my point, which is that no "machine instruction for addition" is invoked. Mathematica did some computation, but basically all to determine that *nothing* should be done. In Scheme, without any definitions (+ a b) --> error a not defined I.e. what happens is that Scheme *evaluates* all three subforms +, a, and b. Well, + evaluates to a built-in procedure <do addition>, but the evaluation of a fails because a doesn't have a value, so Scheme has to stop. >> In Mathematica, one actually is specifying a "pattern" Plus[a,b], > Perhaps I have misunderstood this too, but this doesn't seem right to > ... > The expression a+b isn't a pattern unless it is used in one of those > positions. OK. I was a bit cavalier in my use of the word pattern, which is why I enclosed it in quotes. But the fact remains that the computation above was simply a matter of pattern-matching, and didn't involve any addition. > > One particularly notable result of this pattern-matching behavior is > > that cited in the reference section of Wolfram's book, regarding > > Apply: > > Apply[Plus, g[a,b]] --> a + b > I'm not understanding your concern here either. Although the Apply > function in Mathematica and, for example, the "apply" function in Lisp > or Scheme, aren't identical, they are certainly similar, and the > differences don't represent anything fundamental. For example, Here I disagree. I believe the difference is something fundamental, and is essential to what "apply" is used for in Scheme. > (apply + '(2 2)) > > in Scheme is equivalent to > > Apply[Plus, {2, 2}] > > in Mathematica. Yes, but one would never use quote in the argument to apply! (I assume that you mean a forward quote ', and not a backquote, which as far as I know isn't used for Scheme, but in Common Lisp, refers to a more elaborate quoting that, in your example, gives the same thing.) This is a toy example, of course, because one would write (+ 2 2), just as in Mathematica one would write Plus[2,2] or 2+2 so you might say our disagreement is over superficial things. However, (apply + (2 2)) --> error 2 is not a function in (2 2) would be a closer simulation of Apply[Plus, {2, 2}], and you see the comparison starting to break down. > One of the differences is that the Apply function in Mathematica replaces > the head of the expression (the "car" in Scheme), while the "apply" > function in Scheme includes the "car" as one of the arguments. That is, > (apply + `(g a b)) becomes (+ g a b) while in Mathematica > Apply[Plus, g[a, b]] becomes Plus[a, b]. Additional arguments are > also treated differently, but not in a way that reflects fundamental > differences between the languages. There are fundamental differences. 1) There is no concept of "head" in Scheme!! In Mathematica, the concept of "head" is necessary for pattern matching to be used in the evaluation *all* expressions. "car" is a function which acts on *cons cells* NOT on code. The fact that one can transform cons cells to code by using "read" and "eval" does not make code and cons cells the same. The first element of a Scheme form (f a b) typed into the read-eval-pring loop is evaluated differently, but does not "stick around" as a head. It is replaced by a procedure, defined as the value corresponding to the symbol f, or returns an error if f is not defined. Furthermore, (apply + '(g a b)) --> error g is of type symbol in (+ g a b) is not a useful thing to write in Scheme, because "g" "a" and "b" are not things that can be added, since they are *symbols.* ...[I introduced an example using Apply]... > > Again, unless I have misunderstood something, I don't think this is true. > > While it is correct that (g a b) in (apply + (g a b)) will refer to > a procedure g that will be evaluated before applying +, the same > is true of Mathematica. That is, the g[a, b] in Apply[Plus, g[a, b]] > refers to a procedure g that will be evaluated in Mathematica before > Plus is applied. This evaluation order is used by all of the programming > languages that you mentioned, and is described for Mathematica in the > section 2.5 and appendix A.4 of the reference manual. But if g is not yet defined, Mathematica keeps it as a symbol forming the head of an expression. In Scheme, g is a symbol which is evaluated to, hopefully, return an internal procedure object. If not, you are asking the computer to **do** "g" where "g" is something it doesn't know how to do yet!! Notice that Mathematica doesn't assume you have asked it to *do* anything. g[a,b] will simply give you g[a,b], if g, a, and b has no patterns defined. > Also, since (g a b) might be quoted, as in (apply + `(g a b)), it isn't > entirely true that this procedure will always be evaluated in Scheme. > The purpose of quoting in Scheme is to inhibit evaluation. g is a symbol. '(g a b) is a textual representation of a list of three symbols, g, a, and b. Adding symbols, which is what you are doing in this example, is not defined in Scheme. You seem to me to be confusing the textual representation of code in Scheme with the code that it represents. In an unquoted form which has the *textual representation* (g a b), the symbol g is evaluated to an internal function object, a is evaluated to return some number, and b is evaluated to return some number, and then the internal function *named* g is applied to the arguments *named* by a and b. It is very important to make and keep the distinction between the name and the thing named. This is fundamental in Scheme, as well as philosophy. A similar > effect can be achieved in Mathematica using Unevaluated. That is, > Apply[Plus, Unevaluated[g[a, b]]] will apply Plus to the arguments a and > b even if g[a, b] might otherwise evaluate to something other than itself. > > > I think the desire to "declare variable types" arises from an > > underlying desire to program Mathematica in a procedural or functional > > way. However, Mathematica is, at its heart, a pattern-matching system. > > Whether that is better or worse than a functional or procedural style > > depends on both the particular problem you are trying to solve, and on > > your particular aesthetic approach to problem solving. > > Actually, Mathematica at its heart is a functional language, much like > Lisp or Scheme. Pattern matching is the mechanism that is used for > locating procedures, but it isn't used in any non-trivial way in the > examples that you mentioned. Your comments seem to be about evaluation > order rather than about pattern matching, but evaluation order is > essentially the same in Mathematica as it is in most other languages, > and the connection between these things and variable typing escapes me. If you compare Mathematica's evaluation order to that of Scheme, one find that Mathematica "keeps evaluating until nothing changes." [Or at least tries to, but makes some heuristic guesses to help performance], whereas in Scheme, there is no similar notion. Also, most function definitions in Mathematica are defined using patterns. E.g. g[a_,b_] := a Minus[a,b] *is* a pattern, so pattern matching is used even when you just want functional code. (define g (lambda (a b) (* a (- a b)))) doesn't invoke a pattern matcher when you write (g 3 5) in Scheme. Here is a demonstration of what I found confusing, comparing Scheme and Lisp. ; example in Scheme (define g (lambda (first second) (list first second))) (define a 5) (define b 3) (apply - (g a b)) --> 2 ; because (g a b) returns a list (5 3) (define g-reversed (lambda (first second) (list second first))) (apply - (g-reversed a b)) --> -2 ; because g-reversed returns a list (3 5) (* In Mathematica *) a = 5; b = 3; Apply[Minus, g[a,b]] (* oops, haven't defined g yet *) --> 2 (* well, I don't notice *) Apply[Minus, g-reversed[a,b]] --> 2 (* Hey, what's going on??? g and g-reversed give the same answer. OHHHH!!! I don't have a definition for g-reversed yet. *) g-reversed[first_,second_] := List[second,first]; Apply[Minus, g-reversed[a,b]] --> -2. Of course, these are toy examples, but if the Apply hadn't been typed at the interaction level, but was hidden behind some other code, you might have a very hard time figuring out that you had forgotten to define g or g-reversed, when your code didn't work as you expected!!! It is interesting that the example given in the reference for Apply is Apply[Plus, g[a,b]] --> a + b When this is *completely* contrary to how "apply" is used in Scheme. In fact, you *cannot* write this in Scheme. And the reason is far deeper than "Scheme apply discards the head, while Mathematica apply keeps the head". If g isn't defined, you aren't specifying a computation with g[a,b], but Mathematica doesn't mind. That is an advantage if you want to do symbolic mathematics. In Scheme, however, you are writing functions to do computations, not create symbolic patterns. I think this represents the essential difference between Mathematica and a functional language like Scheme: 1) The Apply routine was defined to superficially resemble Scheme "apply" but the semantics in the example don't exist in Scheme. What apply does in Scheme involves *INTERNAL PROCEDURE OBJECTS* whereas in Mathematica, it does surgery on the internal list form of the things it is passed. By the time Scheme's apply gets to work, the external textual representation of a list does not exist any more. 2) The distinction between the internal representation of a thing and the external representation of a thing is very different in Lisp/Scheme and in Mathematica. That is essentially what I mean when I say that Mathematica is always using "patterns". The representation of g[a,b] is very literally something that is labelled with a head g and has a two element tail containing a and b. In Scheme (g a b) *doesn't* represent any particular internal representation. It describes a *computation*. --Joe Oswald (Aside) Incidentally, many people with only a superficial knowledge of Scheme or Lisp miss the point of (2). They get the idea that "a program in Lisp/Scheme is a list of atoms." In fact, Lisp code is written on the page in the same way that lists of atoms would be written on the page; to some extent, this is superficial. In C, a C program is written as a text file. The compiler takes that text file and changes it to executable code. But the text and the code are different things! One could write a different looking text file in Pascal or in Scheme that could result in the same code. Of course, the resemblance of Lisp code and Lisp data types makes it easy for Lisp programs to write other Lisp programs. C programs that write other C programs can exist, but they are seen as obscure. In Lisp, they are seen as quite ordinary. --Joe