MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

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.


  • Prev by Date: Re: How would you evaluate this limit in Mathematica
  • Next by Date: Re: Re: Types in Mathematica
  • Previous by thread: Re: Re: Types in Mathematica
  • Next by thread: Re: Re: Types in Mathematica