Re: Re: Types in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg62759] Re: [mg62740] Re: Types in Mathematica
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Mon, 5 Dec 2005 03:36:59 -0500 (EST)
- References: <200511191053.FAA16418@smc.vnet.net> <200512032352.SAA15917@smc.vnet.net> <1d9ed0b6bfb55105f8c092de79069cab@jeol.com>
- Sender: owner-wri-mathgroup at wolfram.com
On Saturday 03 December 2005 21:37, Sseziwa Mukasa wrote: > On Dec 3, 2005, at 6:52 PM, Steven T. Hatton wrote: > > I have to say that my definition > > of /strongly typed/ involves compile-time type checking which is not > > something applicable to Mathematica. > > You are correct that strongly typed is ill defined, however the > distinction between compile and run time type checking is not between > strong and weak typing but between dynamic and static typing. > > Generally a strongly typed language disallows the following operation > > <Integer> + <Real> > > unless the user explicitly creates a + operator for integers on the > left and reals on the right. That is not a definition I have used. I recently encountered that definition, but it is not a definition typically used by programmers I know. > Mathematica of course allows addition of > two expressions with head Integer and Real respectively and it is that > fact which makes Mathematica weakly typed. An example of a strong and > dynamic language is LISP, and this is one respect in which Mathematica > differs from LISP. (setq f 1) (setq g 2.2) (setq h (+ f g)) (print h) =>3.2 > C is of course weak and static, Java is strong and > static and that covers the four possibilities. Java certainly supports primitive type conversion, so I don't understand your statement. > > There are Integer, Real, > > Complex, Rational, String and Symbol "atomic" types. Everything else > > in > > Mathematica is constructed of these basic types. > > A List is most certainly not a Symbol, nor is it Complex, Integer, Real > etc. A List is an expression whose Head is a Symbol with value List > applied to zero or more arguments. Hence the idea that everything in > Mathematica is an expression, that's really the only type that exists > (and paradoxically in that sense Mathematica is strongly typed, but in > a universe with only one type it is impossible to distinguish between > strong and weak typing). I don't agree with this. One can say that 1 is an expression with head Integer, but to say that expression is a data type is not much different than saying everything in C++ is a statement. > One can simulate a type system by treating the values of the Heads > differently but that's a simulation and not intrinsic to Mathematica > itself. I'm not sure what you mean. Mathematica treats 1 + 1.5 differently than it treats 1 + "some string". That is intrinsic to the language as it is presented to the user. Without a formal language specification, I know of no other means of determining what is, or is not intrinsic than to examine how Mathematica works "out of the box". > >> You may make arbitrary inquires about the structure of expressions. > >> This > >> is far more flexible and general than any type system, but in simple > >> cases may superfically resemble one. > > > > Can you give an example? > > f[g[x_]] can be considered to be a function that acts on objects of > type g. Since Mathematica is not strongly typed to ensure that we know > the pattern x_ is to be considered of type g we have to explicitly > include the information somewhere, and in Mathematica a convenient > location is the head of an expression. It's not necessary to do it > that way f[{g,x_}] also works and now the type g is represented as a > list whose first element indicates its type. How does that have superficial resemblance to the use of a type system in another language? > > What about predicates which test for types? > > An alternative way of thinking about the predicates which would avoid > confusion about the idea of typing is to imagine them as functions over > the space of all possible expressions mapping a subset to the value > True which subset we then can treat as a type. What confusion? > > Can you explain this in terms of operator overloading in Mathematica > > and > > C++? > > Operator overloading is a restricted version of pattern matching which > is useful in a statically typed environment. Both C++ and Mathematica support operator overloading. Are both of these statically typed languages? Neither of these languages satisfy the criteria you have given for classification as strongly typed. > > How is C++ operator overloading similar to that in Mathematica? > > There are no operators in Mathematica so the idea of operator > overloading is not defined. That is simply not correct. > Of course just as with types, operators can be simulated in Mathematica. What is the difference between associating a function with an operator in C++ and in Mathematica? > > Why > > is that similarity "superficial"? > > Because C++ has well defined constructs called, statements, functions > (or operators) and a host of types and a lot of rules explaining how > they all interact. Mathematica has none of these. You are making assertions which are contrary to the terminology used to discuss Mathematica. > > How does it differ from generic programming in C++? > > One can actually get C++ templates to behave like Mathematica, that's > how Blitz++(http://www.oonumerics.org/blitz/) Blitz++ actually uses a good deal of CPP code in its implementation.