Types in Mathematica thread
- To: mathgroup at smc.vnet.net
- Subject: [mg62708] Types in Mathematica thread
- From: "Kris Carlson" <carlsonkw at comcast.net>
- Date: Fri, 2 Dec 2005 05:53:06 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
Steve Hatton's post [mg62698] Re: Types in Mathematica: I believe most people here will agree that Mathematica is not a strongly typed programming language. In order for us to believe such a thing, we have to have a notion, however vague, of a strongly typed variant of Mathematica. What I really wanted to get at in starting this thread is what that strongly typed Mathematica might be, and what strengths and/or flaws it would have. Rather than trying to address each of the items listed below right now, I am going to post them as potential points of discussion. I really cannot address the questions myself without further thought. What would a type system in Mathematica be? What might be gained by having a type system in Mathematica? What might be lost? To what extent /does/ Mathematica have a type system? To what extent can a type system be implemented within Mathematica without modifying the language? How would a type system in Mathematica be similar to one in another language? How would a type system in Mathematica differ from one in another language? My message: Hmmm, most of you know more than I do about Mathematica and programming but it seems this thread missed some of the mark. I'm harking to Murray's email because he gave the best answer. Please correct me where I'm wrong. A long post but I'm trying to be thorough. 1. Everything is an expression, which is wonderful in its simplicity. Thus since everything is of the form head[body], everything is typed in at least one way via the head, and everything can be tested for its type, eg, with Head[expr]. 2. Where the appropriate head is built in to Mathematica, arguments can be type-tested via x_Integer, x_Real, etc., and in general, x_head. 3. The language provides for the easy creation of our own heads, as simply as writing head[expr] (no error message!), which we would commonly do when creating a datatype. These can be tested with x_head or Head[expr]. 4. There are other built in type tests that rely on other tests than Head: NumberQ, NumericQ, IntegerQ, EvenQ, OddQ, PrimeQ; ArrayQ, VectorQ, MatrixQ (for these there are nice element tests, too), PolynomialQ (element tests). There are built in "structural" tests, and I mention these for the reason mentioned next: SameQ, UnsameQ, OrderedQ, MemberQ, FreeQ, MatchQ, ValueQ, AtomQ. With these, argument-testing syntax is f[x_?testQ]. q.v. Section 2.3.5. 5. Mathematica excels in pattern-matching, which in one form or another (little pun there), is what all these other tests do. There are many built-in high level pattern matching functions and devices. Since we can write our own pattern tests, data typing is limited only by our own ingenuity. Thus, overall, the type-testing and automatic conversion facility in Mathematica exceeds what I have seen rigidly implemented in other languages (I hasten to say I am not broadly educated in other languages.) 6. Taking a statement from Maeder a bit out of context, "In general, such [devices] are powerful tools for proving the correctness of an implementation." He said it in regard to constructors and selectors acting on datatypes. (M220 v1.1, Datatypes) 7. Downvalues are "default" function structures, or "common" functions, or "built-in function" structures, or "broadest class" functions. Upvalues are "special case" functions, or "user-defined" functions / modifications of built-in or default functions, or "narrow-case" functions, or "context-dependent" functions. (This latter is especially important for AI and for a general understanding of the universe.) Mathematica must evaluate special- or narrow-case functions before more general ones or the more general ones would shadow the narrower ones and they would never be seen. Because syntactically Mathematica evaluates from the 'inside out', we wrap the more specialized definitions within broader ones: f[ g[x] ], where f is broader than g. Now quoting from Maeder (and pardon giving it in extenso but I assume most of you don't have access to M220 if I give just a pointer): What is overloading? Mathematica does not provide functions such as plusII[ i1_Integer, i2_Integer], plusRR[ r1_Real, r2_Real ], plusRI[ r_Real, i_Integer }, and so forth. You would not be using it if it did [because it would be a big pain in the rear like we find in other "strongly typed" languages--KWC]. You simply write In[1]:= 1.1 + 2/3 Out[1]= 1.76667 and expect it to work. The standard arithmetic operations are overloaded: they work with data of many different types and perform conversions as necessary. A Template for Overloading. To extend standard operators, such as Plus, Times, and Power, for a new data type with head h use an upvalue h /: x_h + y_h := plusHH[ x, y ] where plusHH[ x, y ] is either an auxilary function you wrote, or a simple one-line expression. For automatic type conversion, use definitions like h /: x_h + i_Integer := plusHI[ x, i ] or reuse existing code, h /: x_h + i_Integer := x + makeH[ i ] where makeH[ i ] is a constructor (type converter) that turns in integer i into a h data element. 8. All the above being said, my conclusion is that Mathematica is a superior language designed and implemented by superior intellects. As Andrzej just said, post a problem to MathGroup before assuming Mathematica can't do something. Kris