Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

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

Search the Archive

Re: Re: Types in Mathematica

  • To: mathgroup at smc.vnet.net
  • Subject: [mg62872] Re: Re: Types in Mathematica
  • From: "Steven T. Hatton" <hattons at globalsymmetry.com>
  • Date: Tue, 6 Dec 2005 23:11:53 -0500 (EST)
  • References: <dn22fb$kum$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

Sseziwa Mukasa wrote:

> On Dec 4, 2005, at 6:16 AM, Steven T. Hatton wrote:

> It also seems it's aside from the general discussion,
> this thread does not appear to be about whether Mathematica is strong
> or weakly typed but about what a type is exactly in Mathematica.

Lets just say Mathematica is "loosely typed", and leave that term loosely
defined.

>>> 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.
> 
> Fair enough but Head[{1,2,3}] is not Symbol.

I would say that we have to be clear about what we mean by "Head[{1,2,3}]". 
At one level, it is nothing but a sequence of characters.  When
Head[{1,2,3}] is evaluated, a downvalue is added to In

In[1]:= Head[{1,2,3}]

Out[1]= List

In[2]:= DownValues[In]  

Out[2]= {HoldPattern[In[1]] :> Head[{1, 2, 3}], 
 
    HoldPattern[In[2]] :> DownValues[In]}

It *could* be that the character sequence Head[{1, 2, 3}] is stored in the
symbol table entry for In with some mechanism used to indicate the
RuleDelayed.  From that observation, one might suggest that the only
"things" that really exist in Mathematica are symbols. 

A.9.2 in the 5.2 Mathematica Book says "A Mathematica expression internally
consists of a contiguous array of pointers, the first to the head, and the
rest to its successive elements."  I find that statement very incomplete. 
When I am finished typing Head[{1,2,3}], and before I evaluate it, it
certainly does not have any internal representation in the kernel.  The
kernel need not be running at that point.  After the input is evaluated, is
there still an internal representation of the expression?  Perhaps I am
wrong about how the DownValues of In are stored.  They may actually be
expressions as described in the appendix.

In any case, (I believe) the leaves of an expression will be atoms of one
kind or another.  The atoms are (AFAIK) the only entities in Mathematica
which hold data.  The only way to access an expression is through some
symbol.  Expressions are composite data structures which form trees whose
subtrees are expressions, and whose leaves are atoms.  Now, by definition
an Atom is an expression, so you can say everything is an expression, but
there are clearly different types of atomic expressions.

>>   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.
> 
> There are different kinds of statements in C++ of which expressions
> are but one class (http://cpp.comsci.us/syntax/).  There are no
> different kinds of expressions in Mathematica all have the same
> structure Head[Arguments...].

How is that different from saying there are atomic expressions and composite
expressions in Mathematica?  Is 1 of the form Head[Arguments...]?  You may
be able to show that it is by playing with the definition for
[Arguments...], but to my way of thingking, 1 just /is/.

>>> 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?
> 
> Because there is no intrinsic type system to which I've added g in
> the sense that declaring a class in C++ adds an explicit new type to C
> ++ along with int, double etc.

But that only says that whatever you did is not like C++ in so much as C++
has a formal definition of "type", and Mathematica does not.  It still
doesn't tell me how it has any resemblance to a type in C++.  I can create
a pseudo type system in C++.  It is not uncommon to find code that uses
such a mechanism, rather than using the builtin type mechanism.

>> What confusion?
> 
> The confusion over exactly what constitutes a type in Mathematica.

Since there is no formal definition, it is strictly a matter of opinion,
and/or convention.  Since there seems to be little in the way of commonly
agreed upon convention, we are stuck with relying on opinion.

>> What is the difference between associating a function with an
>> operator in C++
>> and in Mathematica?
> 
> You can't inspect the structure of the function in C++ because it's a
> function definition and there is no facility for programmatically
> inspecting the contents of a definition in C++.  In Mathematica the
> contents are stored as an expression in the DownValues which can be
> modified as any other expression in Mathematica sans restrictions.

But that really seems to rely on the fact that C++ is a compiled language,
whereas Mathematica is interpreted.  That is certainly an important
distinction.  I'm not sure why that distinction would be any more
significant when dealing with operators than in any other context.  I
believe there are important distinction between the way C++ and Mathematica
support operator overloading.

>>> 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.
> 
> For the sake of brevity and in the correct context clarity, it helps
> to refer to things like Plus[a_,b_] as a function or operator and For
> [...] as a statement but the truth is in Mathematica they are both
> expressions and equivalent in that sense.  Making the distinction may
> be useful to thinking about problems from the programmer's
> perspective but there is nothing within Mathematica itself that
> forces that distinction unlike in C++ where function+(a,b) and for
> (...){} are different.

I don't follow.  I can write a function 

Vector3f plus(const Vecotr3f& v1, const Vecotr3f& v1) {
  return Vector3f(v1.x + v2.x, v1.y + v2.y, v1.z + v2.z);
}

and 

Vector3f operaotr+(const Vecotr3f& v1, const Vecotr3f& v1) {
  return plus(v1,v2);
}

Then write va + vb to add two Vector3f objects.  How does that compare to
overloading + in Mathematica?

> I suppose though that this discussion thread would be helped by
> examples of where some particular definition of type is both useful
> to the programmer and difficult to implement in Mathematica.
> Personally I have found that objects which require complicated state
> information are not trivial to use in Mathematica but I have usually
> found that using a different perspective often obviates the need for
> state in the first place.  With respect to GUI like programs that
> don't lend themselves to the Notebook interface, this is not
> generally the case and as has been said many times on this list
> Mathematica is not suited to the writing of such programs.

When trying to represent an ensamble of interacting physical objects, I find
it useful to be able to maintain state.  In OOP that is fairly
straightforward.  This is why I like development libraries such as
OpenSceneGraph.  I've done similar things with Mathematica, but it has not
been quite as easy.  Part of the problem is that I really didn't understand
Mathematica well when I started using things such as Dr. Maeder's Classes
package.


-- 
The Mathematica Wiki: http://www.mathematica-users.org/
Math for Comp Sci http://www.ifi.unizh.ch/math/bmwcs/master.html
Math for the WWW: http://www.w3.org/Math/


  • Prev by Date: Mathematica and Transcendental Numbers
  • Next by Date: Types in Mathematica
  • Previous by thread: Re: Types in Mathematica
  • Next by thread: Re: Re: Re: Types in Mathematica