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.