MathGroup Archive 2005

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

Search the Archive

Re: Types in Mathematica, a practical example

  • To: mathgroup at
  • Subject: [mg62892] Re: Types in Mathematica, a practical example
  • From: "Steven T. Hatton" <hattons at>
  • Date: Thu, 8 Dec 2005 00:04:19 -0500 (EST)
  • References: <> <> <dn5o99$niv$>
  • Sender: owner-wri-mathgroup at

Sseziwa Mukasa wrote:

> On Dec 6, 2005, at 12:03 AM, Andrzej Kozlowski wrote:
>> It seems to me that you are looking here at Mathematica from the
>> wrong view point. Although Mathematica is not a strict "functional"
>> language, it is "functional" at least in the sense that it is
>> "functions" and not "objects" that play the central role (I am being
>> deliberately vague here but I have run out of patience with long
>> discussions of programming languages and  general design issues.).
> Amen, but apparently I have a masochistic streak that makes me
> persevere in this sisyphean discussion.  At any rate I thought about
> the problem a bit further, I am not sure why, and your point above is
> related to my thoughts.  If one insists on seeing all programming in
> an "object oriented" manner there is an argument that could be made
> for understanding how to make a Symbol x have some desired properties
> corresponding to behavior according to a type.  The first thing one
> must do is forget the Java/C++ model of objects, where objects are
> defined as record structures which can contain associated methods.

That's not quite correct.  The methods in C++ are not actually members of
the instance variables of the class where they are defined.  They are
similar to Dr. Maeder's constructors, selectors, predicates, and operations
for ADTs described in _Computer Science with Mathematica_.  

> Instead the appropriate model is Smalltalk, where the definition of a
> method on a variable defines the behaviors of the class to which that
> variable belongs.

Methods in Smalltalk are not that different from member functions in C++. 
Both instance methods and class methods (similar but not identical to
static member functions) are defined as part of the class, not the
instances.  The big differences between Smalltalk and C++ are:

C++ has no universal base class. Java does.
C++ doesn't have a Class object for each class. Java does.
C++ doesn't use a virtual machine. Java does - except with GCJ.
C++ doesn't have, or need Garbage collection. Java does.
C++ variables are declared with an immutable type.  Same as Java.

Perhaps it's this last point which you are intending?  I will grant that
Mathematica symbols are not immutably bound to the values assigned to them,
and "type" is determined by the currently associated values.  This is also
how Lisp variables work.

>> In
>> this case the issue is with the function Plus and not with the nature
>> or "type" of x etc. Plus has the attribute Listable, which is
>> responsible for the behaviour you see
> Agreed, so the "object oriented" approach would be to redefine the
> Plus method on x to get the behavior we desire.

Not sure what you mean here.  In C++ you would overload Plus for your type. 
But that begs the issue of defining a type for x.  

After thinking it over, my answer to Ingolf's original question is "that's
the way Mathematica works.  Symbols do not have immutable types.  You have
to be sure your arguments are symbols with the correct 'types' assigned to

> Of course, but I think the idea in this thread is to deal with the
> idea of types and their implementation in Mathematica.  The evaluator
> does not easily fit into a model of types.  I think what should be
> clear though is that unless there is a very good argument for
> developing the infrastructure necessary to redefine the behavior of
> Mathematica expressions globally, development of a type system
> infrastructure is probably far more work than it's worth.

That may well be the case.  I must say, not everybody has jumped on Dr.
Maeder's bandwagon regarding ADTs an OOP.
The Mathematica Wiki:
Math for Comp Sci
Math for the WWW:

  • Prev by Date: Re: Bug in Graphics output of Circle primitive?
  • Next by Date: Re: FixedPoint stops "when elements no longer change"?
  • Previous by thread: Re: Re: Re: Types in Mathematica, a practical example
  • Next by thread: Re: Types in Mathematica, a practical example