Re: Types in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg63038] Re: Types in Mathematica
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Sun, 11 Dec 2005 04:57:34 -0500 (EST)
- References: <dn22fb$kum$1@smc.vnet.net> <200512101438.jBAEcJp1031941@ljosalfr.globalsymmetry.com> <36882fc282d0c1e46b51b2cbd4fe8b43@jeol.com>
- Sender: owner-wri-mathgroup at wolfram.com
On Saturday 10 December 2005 20:10, Sseziwa Mukasa wrote: > On Dec 10, 2005, at 9:38 AM, Steven T. Hatton wrote: > I meant message in the sense of Message[Arguments], from now on when > talking about Mathematica expressions I'll capitalize the first letter > and use lower case when some other meaning is intended. Rereading > these messages though, I notice that I'm a poor editor of emails so > there will be mistakes. Oh, now I see what you meant. Part[Complex, 1]. To be pedantic, it doesn't actually "return" the Message. It displays it, and returns Complex\[LeftDoubleBracket]1\[RightDoubleBracket]. > > I'm talking about > > creating things as composite expressions and treating them _as if_ they > > were atomic. > > Perhaps doing this in pursuit of a specific application would be > helpful. I've notices the occasional relativist (the physics type not > the philosophic type) who is looking to use Mathematica to represent > tensors and the other structures they work with symbolically. I > believe there is a package that does so already, but if there is a > candidate for something that should act like and Atom but is not one I > suppose that's it. I know far too little of what researchers in > relativity do to be able to pursue that idea further. That is actually one of my primary interests. Interestingly, I have discovered the formulae describing hurricanes look a whole lot like those in general relativity. That was the impetus for my returning to Mathematica. WRT tensor packages, the moderator of this newsgroup created a commercial package called MathTensor. It's pricy. At least for my current situation. I'm not sure why the Unix version (I assume that includes Linux) costs $230 more than the $570 price for the Mac and Windows versions. When I feel confident with my Mathematica skills, I may consider buying it. I don't expect it to be OOP based. > Many modern languages have rejected the type system used by the various > C and Algol derived languages: Haskell, ML, Mercury, Prolog, Dylan, > Common Lisp... I know a lot of people are happy with C++ but as far as > I can tell from programming language designers it is not really an > interesting path to follow. It's also a hard act to follow. D is the closest thing I know of to a serious effort to improve on the C++ principles. You can find more here: http://digitalmars.com/d/comparison.html C++ has some problems. Many of them have to do with the fact that it strives to be C compatable. One thing I've learned from studying C++ is that the builtin features of other languages can usually be implemented or emulated in C++. In many respects, it's good that C++ hasn't incorporated every newfangled idea that's come along. It really is intended to be a basis for building complete development systems, and not such a system. IMO, one of the biggest problems of C++ is the fact that too many people treat it like C. > > Was it just a question of who could yell loudest or pout longest, or > > were there solid reasons for not taking that approach? > > I suggest reading up on Hindley-Milner type systems, they seem to be > the rage in statically typed functional languages. It would seem a likely candidate for Mathematica. I don't know if you were suggesting a reason why there isn't a comprehensive type system in Mathematica. > > What would happen if users could define Atom-like types? That is, > > types > > that only expose their content through an interface. Whoops! That's > > OOP! > > There's nothing inherently wrong with OOP but it achieved prominence on > the back of C and Algol like languages and those implementations of OOP > systems create issues that other languages simply don't have. For > example at least one person > (http://norvig.com/design-patterns/ppframe.htm) thinks the Gang of Four > would not be earning a dime of royalty or consulting fees if they used > a dynamically typed language because most of their patters are trivial > in other idioms. The web browser I used to access his powerpoint slides was written in C++. PowerPoint (AFAIK) was written in C++. The mail client I am using was written in C++. The window manager I'm using was written in C++. His critique was written a decade ago. > What determines the value is the evaluator, what holds it is some > expression, in this case one with the head Real. What I really want to know is, given a symbol s with Head[s]===Complex, how does the evaluator obtain the precursor values for calculating the returned value of Arg[s]? > > They _are_ the rewrite rules. At least from the user's perspective. > > Do you > > not agree? See 2.6.2 in the Help Browser. > > I agree that that is what they are, and their existence makes it > possible to write self modifying code pretty easily should the need > arise. But they are not necessary. What are the alternatives without significantly modifying the language? > > I am willing to bet they are simply bits in a single int variable in > > the > > Symbol struct. What the consequences of their being there are, is a > > different story. They may well be arguments to a switch statement. > > Again we're thinking on different levels, I'm not really interested in > what the implementation of Mathematica looks like (I understand it's a > blend of C and Mathematica itself). I'm interested in how one would > model the evaluator in the abstract. I don't believe you will in general find easy ways using Rule[] to produce behavior equivalent to that which results from Attributes being set. It way I view the evaluation is that the evaluator encounters the symbol and queries it for certain kinds of data relevant to the current state of the evaluator. There is a set of rules to determine the next state depending on the values obtained from querying the symbol and the current state of the evaluator. After obtaining all the values, the rules are applied, and the evaluator transitions to the next state. > In my job our product is a blend of an interpreted language and an > internal implementation in another language and I can honestly say that > there would be no enlightenment for someone seeking to understand the > interpreted language to look at its implementation. I really don't care so much whether I know how Mathematica is implemented in the Kernel. I am, however, interested in an abstract model of that implementation. The fact of the matter is, I would probably not like the way Mathematica is written. At least if the MathLink code is any indicator. > > I don't agree. The items I listed are the abstract data members of the > > "type" Symbol. The evaluator doesn't have rewrite rules any more than > > a > > compiler has function definitions. The rules exist in the expression > > structure passed to the evaluator. > > Regardless of how the evaluator actually works, the question is how you > can reason about it accurately with respect to generating the correct > output for a given input (even if you get the algorithmic complexity > wrong). I submit that the correct way to think about it is as a > rewrite system, as others have said. That is exactly what a CPU is. But viewing it as simply a rewrite system does not help much when the necessary knowledge determing how it works is scattred throughout a 1500 page book. It would be nice if that level of functionality were explained in a more coherent and structured way. I have books on every language from Old Norse to the bash shell. They almost all have some kind of tree diagram representing grammatical structures. Those tools are completely applicable to Mathematica, but I have _never_ seen them used. Steven