Re: Types in Mathematica

*To*: mathgroup at smc.vnet.net*Subject*: [mg63031] Re: Types in Mathematica*From*: Sseziwa Mukasa <mukasa at jeol.com>*Date*: Sun, 11 Dec 2005 04:57:07 -0500 (EST)*References*: <dn22fb$kum$1@smc.vnet.net> <200512081442.jB8EgCda002721@ljosalfr.globalsymmetry.com> <F44AB4A1-92CA-49D7-ABDD-E94D8270B8EC@jeol.com> <200512081419.17348.hattons@globalsymmetry.com> <dnbmt9$5qf$1@smc.vnet.net> <-4qdnaBC0M37OgTeRVn-uQ@speakeasy.net> <dned7g$6d$1@smc.vnet.net> <200512101438.jBAEcJp1031941@ljosalfr.globalsymmetry.com>*Sender*: owner-wri-mathgroup at wolfram.com

On Dec 10, 2005, at 9:38 AM, Steven T. Hatton wrote: > Atoms really do seem to satisfy the definition of abstract data type. > One > might even say they satisfy the definition of object in the OOP sense. Sort of, they are a decent candidate. >> Part cannot take anything beyond the 0th >> (head) element of atoms, Part returns a Message > > I'm not sure I would use the term "Message" here. But then, "message" > is > something I consider specific to SmallTalk, and not generally useful > when > discussing OOP. 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. > 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. > It appears Maeder would have had a stronger type > system in Mathematica. [deleted] I suspect there were > discussion about this sort of thing in the early days, and the notion > of a > type system along the lines of C++ was rejected. 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. > 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. > 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 value of Arg[1+I] is Arg[1+I] > > Are you talking about the pattern, or the result given by evaluating > the > expression? Both since an equation is a tautology. A better way at looking at values in a rewrite system though is a value is what happens when there are no more rewrite rules left after applying them to the initial expression in which case the value in Mathematica is Times[Rational[1,4],Pi]. Similarly the value of Unevaluated[Arg[1+I]] is Arg[1+I] since you have to submit the argument of Unevaluated to the evaluator again. > Indeed, another pit of vipers I seem to have stepped into. What I > should > have written was What determines (holds) the value of Arg[1+I]//N? What determines the value is the evaluator, what holds it is some expression, in this case one with the head Real. >> Since there are rewrite >> rules associated with Arg one has to be careful about when they look >> at an Arg expression depending on what they want to do with it. > > This is certainly a point of frustration I have with Mathematica. If > I look > at the documentation for Arg[], I am not given a comprehensive > description > of its behavior. A large part of the Mathematica Book is dedicated to describing the evaluator, it would be redundant to repeat it every time. >> While we continue on our tour of programming languages the >> logic languages > > ?? What do you mean here? Can you provide an example? I have been > glancing at SML over the past few days. I also compiled and crashed > Axiom. I was thinking of languages similar to Prolog, but this is aside from the topic of this thread. >>> UpValues >>> DownValues >>> OwnValues >>> SubValues >> >> These things are side effects of the evaluator, like In and Out, not >> fundamental. They are very useful though because they describe >> expressions we can use to interact with the rewrite rules used by the >> evaluator itself. > > 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. >> Attributes are definitely an interesting beast, I'm not sure but I >> suspect they can be considered a special set of rules used by the >> evaluator. > > 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. 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 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. Regards, Ssezi

**Re: Types in Mathematica**

**Re: Types in Mathematica**

**Re: Types in Mathematica**

**Re: Types in Mathematica**